search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.65k stars 644 forks source link

Consideration for HTTP/3 Security #1798

Open ImanSharaf opened 8 months ago

ImanSharaf commented 8 months ago

With the growing adoption of HTTP/3, it's crucial to address security concerns specific to its protocols and implementations. One key area is the header compression mechanism used in HTTP/3, known as QPACK. While QPACK enhances efficiency, it may also introduce vulnerabilities similar to those seen with HTTP/2's HPACK, particularly compression-based security attacks like CRIME and BREACH.

To start this discussion around HTTP/3 security, I want to propose this:

elarlang commented 8 months ago

I tried to get more into the issue, searched some materials, and found to be worth reading:

Then I found a blog post:

So, instead of keeping digging myself, I hope @Sjord can give us a quick overview:

Sjord commented 8 months ago

A compression side channel attack is possible when some content contains both a secret and some user input and is then compressed. The assumption is that the attacker can observe the size of the compressed content, but not the content itself (because it is encrypted). Compression is more effective if the user input is more similar to the secret, so if the size decreases the attacker knows he is on the right track.

BREACH targets compression of the request content. By sending many requests through a CSRF-like setup, and observing the size, a secret value in the request content (typically the CSRF token) can be guessed approx. one bit at a time.

HPACK and QPACK have some mitigations against this, but do not offer total protection. Headers are not compressed at character-level, but headers with the same value are still compressed. This makes it impossible to guess character by character, so this makes the attack much harder.

From RFC 9204:

QPACK mitigates, but does not completely prevent, attacks modeled on CRIME by forcing a guess to match an entire field line rather than individual characters. An attacker can only learn whether a guess is correct or not, so the attacker is reduced to a brute-force guess for the field values associated with a given field name.

The usual recommendations of using sufficiently long keys and CSRF tokens would adequately prevent against a brute-force attack. We could also recommend to be cautious when using user-supplied information as header value. However, I think adding a requirement to never include user content in a request header may be a bit too much.

The typical attack scenario for BREACH was performing many CSRF-like requests. Same-site cookies make this scenario a lot harder. A possible attack scenario is when a web application accesses another service: it includes the API key in the request header, and also forwards the client's User-Agent header or some other header. However, the attacker then also needs a MitM position to observe the size of the compressed requests.

introduce vulnerabilities similar to those seen with HTTP/2's HPACK

Do you have more specific information or a source for this? I was under the impression that HPACK in HTTP/2 was not vulnerable to compression attacks.

jmanico commented 8 months ago

(AI driven search on HPACK)

HPACK (Header Compression for HTTP/2) is designed to be resistant to compression-based attacks, such as CRIME and BREACH, which exploited vulnerabilities in earlier HTTP compression methods. These attacks leveraged the fact that the size of the compressed payload can reveal information about the contents of the encrypted data, particularly when an attacker can control part of the input.

In HPACK, a few key strategies are implemented to mitigate such vulnerabilities:

  1. Static and Dynamic Tables: HPACK uses a combination of static and dynamic tables to encode headers. The static table contains common HTTP headers, and the dynamic table is built during the communication session. This approach ensures that repeated headers do not lead to a size change in the compressed data.

  2. Huffman Coding: HPACK uses Huffman coding for the representation of header names and values. While Huffman coding is a form of compression, it does not suffer from the same security issues as other compression schemes, since it does not vary the size of the output significantly based on the repetition of input values.

  3. Limitation on Stateful Dynamic Compression: HPACK limits how much of the headers are dynamically compressed. By controlling the amount of state shared between client and server, it reduces the potential for information leakage through changes in the size of the compressed headers.

  4. No Compressing of Sensitive Data: HPACK avoids compressing sensitive headers (like cookies and authentication tokens) that are often targeted in CRIME and BREACH attacks.

tghosth commented 7 months ago

@Sjord so to be clear, are we saying that HTTP/3 is vulnerable to this attack in a way that HTTP/2 is not?

Sjord commented 7 months ago

No, I don't think there is a large difference between 2 and 3 regarding security against compression side channel attacks. How did you get that idea?

tghosth commented 7 months ago

Maybe I misunderstood what @ImanSharaf wrote here: https://github.com/OWASP/ASVS/issues/1798#issue-2021683053

@ImanSharaf is there anything HTTP/3 specific here or do we need a more generic requirement?

danielcuthbert commented 4 months ago

I don't think there exists a need yet for specific mentions of HTTP/3 in this standard, as we don't delve deep into the underlying webserver part. However, there might be a need at some point and I'm open to any suggestions as to what

tghosth commented 3 months ago

I am going to leave this as open but not blocking for 5.0

ImanSharaf commented 3 months ago

@tghosth this requires an extensive research, thank you.