-
Notifications
You must be signed in to change notification settings - Fork 103
Web security
Tempesta FW implements a lightweight WAF (Web Application Firewall). Tempesta FW's core works in OS deferred interrupt context (softirq), so only quick security checks can be done. More features will come with the Kernel-User Space Transport. Nevertheless, Tempesta FW should be considered as a WAF accelerator which can offload many checks from more advanced WAFs and protect them from DDoS attacks or usual overloading.
The most famous injection attacks are XSS, command injection, and SQL injections. A classic example of passive XSS attack (requiring a client to click a malicious link) is
http://www.site.com/page.php?var=<script>alert('xss');</script>
It worth to mention that XSS attack also can use Cookie, Referer or Host headers, e.g. famous WordPress XSS vulnerability in RSS Feed Generator.
Another example is SSRF attack, which can use malformed URI to get access to internal company resources, e.g.
http://example.com/?id=https://192.168.0.1/private
Google was attacked in 2016 with Relative Path Overwrite (RPO) with following line in the URI:
/tools/toolbar/buttons/gallery?q=%0a{}*{background:red}/..//apis/howto_guide.html
(note the anomaly characters {, }, : in the URI).
Tempesta FW verifies URI and all HTTP headers against allowed by the RFC
alphabet. You also can restrict the allowed characters for your web application
(e.g. exclude {, }, : from the allowed alphabet in the Google's case).
In particular, characters < and > aren't allowed by the RFC, and
so a request containing such URI will be blocked by Tempesta FW. For the
WordPress example
$ curl -H "Host: \"><body onload=alert(String.fromCharCode(88,83,83))>" http://www.example.org/blog/feed
all the special symbols, such as >, <, =, (, ) are blocked by
Tempesta FW's Host header parser.
To restrict allowed characters set in a particular HTTP field, such as URI or
Cookie value, you can use
custom characters sets.
For example, to limit your URI content to only [a-zA-Z0-9/-%*] use following
configuration option:
http_uri_brange 0x25 0x2A 0x2D 0x2F 0x30-0x39 0x41-5A 0x61-0x7A;
http_uri_brange defines allowed alphabet for abs_path defined by RFC 7230,
so the SSRF example above can be filtered out by simple prohibition of : in
the http_ur_brange.
If your web application works with user accounts, then typically it requires a user authentication. If you implement the user authentication on your web site, then an attacker may try to use a brute-force password cracker to get access to accounts of your users. An attacker can try many passwords for each known user name (i.e. you'll see many authorization requests for the same user name, but with different passwords) or use a database with user name and password pairs (now you'll be seeing many different login/password pairs - just like many users are trying to authorize). The second case is much harder to detect. It's worth mentioning that unsuccessful authorization requests typically produce error HTTP responses.
Tempesta FW provides limiting facility for efficient blocking of all types of password crackers (read more at Frang configuration page), e.g.
http_resp_code_block 401 403 10 3
blocks an attacker's IP address if a protected web application return 10 error responses with codes 401 or 403 within 3 seconds.
HTTP Request Smuggling (or original article or slides) attack becomes possible when one or more HTTP entities (e.g. proxy server or web application firewall (WAF)) are between the user and the destination web server.
There are a bunch of techniques, but in the essence this techniques provide a way for an attacker to bypass proxy or WAF's filtering for instance by leaking through them if be blocked otherwise or by presenting different (one or even many at once) request to web server and to proxy or WAF.
Most commonly the techniques rely on a fact that WAF (or proxy) do blacklist, not whitelist filtering. So not known (for example ancient standard conforming), fitting exception rules, mutated in some way or non-standard requests may leak through. Some of the techniques includes:
Doubling Content-Length headers in the request. As a result, HTTP entities parsing the request may each use a different header.
To mitigate this type of attack Tempesta FW rejects as invalid HTTP messages which
have both a Transfer-Encoding and a Content-Length headers or HTTP messages
which contain multiple Content-Length headers.
HTTP 0.9 conforming requests. Pre-standard HTTP requests can be just one-liner without HTTP-version field in the first line of the message and without headers, may contain absolute URL in GET request with parameters. Pre-standard HTTP requests still supported by some major web servers, and some may support even headers and POST requests in them. Example of pre-standard HTTP request: GET http://some.site/?param=value. Tempesta FW rejects these messages.
HTTP Pipelining. HTTP standard allow to reuse connection for multiple messages, for example:
GET /sum.jsp?a=1&b=1&c=2&d=2 HTTP/1.0
Host: asitename.com:8080
Connection: keep-alive
POST /sum.jsp?a=5&b=5 HTTP/1.1
Host: asitename.com:8080
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
c=6&d=6
WAF should send all requests (aside from some edge cases) to web server. As such there is no any vulnerability in it, but in connection with other techniques (HTTP 0.9) this may prevent WAF from proper filtering of subsequent messages in connection and it will be leaked through. For instance:
GET /index.jsp HTTP/1.1
Host: victim.com
Content—Length: 10
1234567890GET https://victim.com/reset.jsp
Tempesta FW properly parse all pipelined messages and do filtering on each of it.
HTTP headers line folding. In past http standard let headers be multiline extending header that starts with CR/LF followed by a horizontal tab or space character. For example:
GET /page.do?p1=v1 HTTP/1.1
Host:
www.filtered.com
That was obsoleted (almostly) by RFC7230. Tempesta FW overall rejects message with such headers. Tempesta FW does that, but keep in mind that header with line folding stops parsing not only the message but all subsequent messages in connection.
HTTP verb rewriting. POST requests with payload may leak through WAF if their HTTP method will be replaced with GET due to no defined semantics of GET messages payload. Citation from RFC7231#section-4.3:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Example of such requests:
GET /path/sample.aspx?input0=0 HTTP/1.1
HOST: victim.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
input1='union all select * from users--
Especially this technique exploitable with conjunction with other mentioned or not mentioned here techniques. As standard let recipients to decide if they should reject GET messages with payload it would be standard conforming to reject them. Tempesta FW rejects such messages.
HTTP Response Splitting is also a type of injection attacks, so it can be mitigated by strong alphabet validation. Besides the input validation Tempesta FW counts number of requests and responses and warns a system administrator if they don't match, i.e. the attack took place.
Host header must be validated to prevent DNS rebinding attack, so it's recommended to use HTTP Tables, e.g.
listen 192.168.100.4:80;
srv_group test_grp {
server 127.0.0.1:8080;
}
http_chain {
host == "*.test.com" -> test_grp;
}
, now any request out of test.com domain in Host header will be blocked
by Tempesta FW.
Attacks exploiting race conditions in a Web application require many concurrent requests, so it's recommended to use rate limiting to prevent the attacks.
Most widespread attacks on cache subsystem are:
- cache depletion,
- cache poisoning.
With cache depletion attacks intruders are trying to exhaust cache system on Application delivery controller and to vastly increase number of backend server requests making it unreachable by end user. Another type of attack here -- is forcing to cache private responses and make them publically available. To cope the attack TempestaFW analyses both request and responses and avoids caching private responses. For full cache depletion attack mitigations Frang limits will be used, but the feature is under development.
Cache poisoning attacks are targeted on filling the web cache by incorrect responses. E.g. temporal backend server errors can be cached or intruder may forge the request so ADC and backend server will understand the request in very different manners. See CPDoS for examples. To mitigate the attack TempestaFW doesn't cache error responses as stated in the relevant RFCs and parses additional well-known not-standarded headers that might cause the cache issues. TempestaFW is not vulnerable for attacks listed in CPDoS whitepapers.