Proposal to Add "Cookie Bomb" Attack Vector to ASVS about asvs

[elarlang]

And it's not only about cookie length, some web servers also can not handle certain symbols in cookie values (nowadays browsers are getting more restrictive on the topic and you can not write all symbols to cookie value anymore).

Example with Apache Tomcat which I reported 9 years ago: https://seclists.org/bugtraq/2014/Sep/51

[jmanico]

Sometimes… 😉

[elarlang]

Link points to 8 year old situation.

Have you tried it in practice yourself?

If you write 2 cookies with max length (4k), you alread hit "431 - Request Header Fields Too Large" error.

https://datatracker.ietf.org/doc/html/rfc6585#section-5 RFC does not say what the limit is, I have not seen it more than 8kB long time.

Based on my experience it's not valid anymore.

[elarlang]

Applications should have mechanisms in place to limit the number and size of cookies that can be set for a user.

Browsers have those limit as well, different browsers a bit different, but you can not write endless amount of cookies to the browser. Based on my knowledge, for an application it is impossible to control it. You can only cleanup everything with:

Clear-Site-Data: "cookies"

[ImanSharaf]

The users can delete the cookies and then it would fix their issue. But the most recent write-ups that I found in HackerOne are these two:
2020: Nord
2020: Uber

I've opened this issue to ensure comprehensiveness within the framework.

[elarlang]

So this is not large number of large cookies - it is exactly hitting this 8kB limit for the browser and then this browser will get always given error, which I call "Client-Based Denial of Service" (you need to infect each client separately).

[elarlang]

In this situation, often an application will not get the request, as web server serves the error (depends on solution).

As a defense on my training I recommend to have filters on WAF:

• only cookies with those names which the application needs
• only with expected value pattern (to allow only allowed characters and avoid 4kB values for allowed cookie names)

[ImanSharaf]

Based on my knowledge, for an application it is impossible to control it. You can only cleanup everything with:

While browsers do have a limit on the number and size of cookies they accept for a domain, it's important to understand that the application itself can play a significant role in controlling the cookies it sets. Even before the browser limits come into play, the application can decide not to set a cookie in the first place. The application can also decide on the size of each cookie.
You're right about the Clear-Site-Data: "cookies" header. It's a way to instruct the browser to clear cookies for a site. However, it's a mitigation measure or a cleanup mechanism rather than a preventive measure.
While useful, especially in scenarios like post-logout, it isn't directly related to prevention.

[elarlang]

The attack surface is a lot wider - you can write matching cookie from every subdomain (if you have cookie writing solution there, like "XSS"). One "XSS" in Same-Site scope is enough and you can not defend against it with application itself.

[ImanSharaf]

As a defense on my training I recommend to have filters on WAF:

Configuring the WAF could be a solid solution. It's important to remember that while WAFs provide an essential layer of security, they should not be the sole line of defense.

[jmanico]

This is just a type of XSS payload, and is fixed via normal XSS defense.

[elarlang]

This is just a type of XSS payload, and is fixed via normal XSS defense.

First: #1739 (comment)

Think about ISP giving for your internet connection hostname like here-is-your-ip.something.isp.tld, which means you can write matching cookies for every *.isp.tld from your own hosted HTTP service.

Also the vector may come available when user controls some part of the value which will be written to a cookie (by the application).

It stays valid even we merge requirement "one application per hostname" (#1299), as for cookies the scope is Site.

[ImanSharaf]

This is just a type of XSS payload, and is fixed via normal XSS defense.

This code is vulnerable to Cookie Bomb but is not vulnerable to XSS

from flask import Flask, request, make_response
import bleach

app = Flask(__name__)

@app.route('/')
def index():
    # Return a basic web page that doesn't reflect user input.
    return "Welcome to our website!"

@app.route('/setcookie', methods=['POST'])
def setcookie():
    # Get the user input
    key = request.form['key']
    value = request.form['value']

    # Sanitize the value using bleach
    sanitized_value = bleach.clean(value)

    resp = make_response("Cookie set!")
    resp.set_cookie(key, sanitized_value)
    return resp

if __name__ == "__main__":
    app.run()

[jmanico]

I stand corrected, nice Iman!!!

[ImanSharaf]

Thanks for being open to feedback.

[elarlang]

Conclusion so far: requirement proposal: #1739 (comment)

[tghosth]

Hi folks, I read through the comments above.

It seems to me that this would only be possible in two ways:

1. An attacker can directly set the value of a cookie for a victim
2. An attacker can indirectly set the value of a cookie for a victim, for example by sending them to a very long URL which the application then writes into the cookie value.

I am not convinced that 1) should be possible but I would welcome being corrected :)

For 2) this is an untrusted/user-controlled input problem and we would need to either create a requirement or adapt an existing requirement along these lines.

Do you disagree @ImanSharaf @elarlang @jmanico ?

[jmanico]

XSS allows for "cookie clearing" or "setting new cookies"

[elarlang]

An attacker can directly set the value of a cookie for a victim

I can not actually understand what do you mean with that.

An attacker can indirectly set the value of a cookie for a victim, for example by sending them to a very long URL which the application then writes into the cookie value.

This is more input validation question and controllable by application. Even if you fix that, it does not solve to issue here.

Let's say we have target site on hostname www.moreaboutcookies.com.

Cookie security policy is based on Site, which means an attacker can write cookies, mathcing to www.moreaboutcookies.com from Same-Site scope: *.moreaboutcookies.com.

Example possibilities:

From directly www.moreaboutcookies.com

• "XSS" (JavaScript injection or execution) vulnerability
• not validated user-input, which goes to set-cookie value

From *.moreaboutcookies.com (every subdomain)

• every subdomain can write cookie with Domain value .moreaboutcookies.com and it will be sent by browser to www.moreaboutcookies.com
• one "XSS" in *.moreaboutcookies.com is enough
• one attacker controlled set-cookie command from *.moreaboutcookies.com is enough

If www.moreaboutcookies.com does not have Strict-Transport-Security set with includeSubdomains, then an attacker can "call" victim in own-controlled network to http://thisisnotvalid.moreaboutcookies.com and write cookies there.

[tghosth]

An attacker can directly set the value of a cookie for a victim

I can not actually understand what do you mean with that.

I just mean that an attacker can some how write directly into the cookie value/cookies collection in the victim's browser. As I said, this should conceptually not be possible although I guess you could do it through XSS but then the fix is to not have XSS.

An attacker can indirectly set the value of a cookie for a victim, for example by sending them to a very long URL which the application then writes into the cookie value.

This is more input validation question and controllable by application

I agree.

Even if you fix that, it does not solve to issue here.

I don't agree. This seems to be the only situation that is actually directly a problem here.

Let's say we have target site on hostname www.moreaboutcookies.com.

Cookie security policy is based on Site, which means an attacker can write cookies, mathcing to www.moreaboutcookies.com from Same-Site scope: *.moreaboutcookies.com.

Example possibilities:

From directly www.moreaboutcookies.com

• "XSS" (JavaScript injection or execution) vulnerability

Fix by preventing XSS (which they should already be doing)

• not validated user-input, which goes to set-cookie value

Fix with input validation as we said above.

From *.moreaboutcookies.com (every subdomain)

• every subdomain can write cookie with Domain value .moreaboutcookies.com and it will be sent by browser to www.moreaboutcookies.com
• one attacker controlled set-cookie command from *.moreaboutcookies.com is enough

This seems really niche because it means the attacker has control of an app subdomain, no and also this:
https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=73

• one "XSS" in *.moreaboutcookies.com is enough

Again, fix by preventing XSS

If www.moreaboutcookies.com does not have Strict-Transport-Security set with includeSubdomains, then an attacker can "call" victim in own-controlled network to http://thisisnotvalid.moreaboutcookies.com and write cookies there.

Pretty sure we require HSTS and also this which should hopefully cover this situation?
https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=73

So, in summary, I still think we need an input validation or sanitization requirement to address the indirect part of this issue.

[elarlang]

__Host- do not help here - attacker can use whatever name for cookies. __Host- is for protecting application own cookies from overwriting from same-site scope, but this is not the case here.

attack scope is same-site - "fix XSS on all subdomains" is outside of application scope and an application security should not depend on outside environment. Every a bit larger corporation has many subdomains for their main domain.

[tghosth]

So aside from sanitization when taking user input into a cookie, what additional protection/requirement are you advocating here @elarlang ?

[elarlang]

There not much else you can do - in this scenario you can not control the source (like go and fix the XSS).

Another option is to use Clear-Site-Data for cleanup, but it clears all the cookies from Same-Site scope and not supported by all browsers.

[tghosth]

There not much else you can do - in this scenario you can not control the source (like go and fix the XSS).

So this is kinda my point, as I said in #1739 (comment), we can create an input validation requirement but that is about it.

Would you be comfortable for @ImanSharaf to try and draft a requirement?

[elarlang]

we can create an input validation requirement but that is about it.

No, we can not - HTTP server just responds with 400 or 431 and this request don't even reach to the application.

... also, there is nothing to validate, as the application do not use this information.

Just the web server fails to handle the request.

[tghosth]

we can create an input validation requirement but that is about it.

No, we can not - HTTP server just responds with 400 or 431 and this request don't even reach to the application.

... also, there is nothing to validate, as the application do not use this information.

Just the web server fails to handle the request.

The input validation is not for after the cookie has been bombed but rather to prevent it from happening.

I mentioned this above #1739 (comment)

2. An attacker can indirectly set the value of a cookie for a victim, for example by sending them to a very long URL which the application then writes into the cookie value.

...

For 2) this is an untrusted/user-controlled input problem and we would need to either create a requirement or adapt an existing requirement along these lines.

The examples which Iman brought were along this line.

[elarlang]

Aha, ok. I overlooked this part. I agree this should be fixed with input validation in the same application but for me it's covered by basic input validation rules.

[tghosth]

Aha, ok. I overlooked this part. I agree this should be fixed with input validation in the same application but for me it's covered by basic input validation rules.

@ImanSharaf, do you think this is covered by existing input validation requirements or do you have a suggestion for an additional requirement?

[elarlang]

Aha, ok. I overlooked this part. I agree this should be fixed with input validation in the same application but for me it's covered by basic input validation rules.

Some practice made me rethink some things... I think it makes sense to have separate requirement to address problems:

• limitation on the browser side: if user-controlled input reach to cookie value (or name), including base64 or inside JWT - browser must be able to write the cookie, so the cookie key=value can be max 4096 bytes (https://datatracker.ietf.org/doc/html/rfc6265#section-6.1)
• limitation on the server side: all cookie key-value pair lengths combined should not be longer than allowed max request field length (https://datatracker.ietf.org/doc/html/rfc6265#section-5)

[tghosth]

What do we think about the following requirement:

Verify that any untrusted input is validated for length before being included in a cookie. Where a derived cookie value such as a JWT is being stored in a cookie, the validation should be applied to the relevant parts of the derived value.

[jmanico]

I like it, but can you use a different language than "the validation should be applied to the relevant parts of the derived value." I am not 100% sure what that means.

[tghosth]

What do you think @elarlang @jmanico ?

Verify that any untrusted input is validated for length before being included in a cookie. Where multiple inputs are being combined into a single cookie value such as a JWT, the validation should be applied to each relevant input separately.

[jmanico]

Excellent

[tghosth]

Any further comments @elarlang ?

[elarlang]

I propose a bit different direction:

Verify that untrusted input, including being part of JWT, is validated for length before being included in a cookie and that the cookie name and value length combined are not over 4096 symbols.

[tghosth]

Verify that untrusted input is validated for length before being included in a cookie (including as part of a JWT) and that the cookie name and value length combined are not over 4096 bytes.

@elarlang minor tweaks

[ImanSharaf]

Verify that untrusted input is validated for length before being included in a cookie (including as part of a JWT) and that the cookie name and value length combined are not over 4096 bytes.

@elarlang minor tweaks

Sorry for the delay, this works for me.

[tghosth]

Created #1865.
I ignored CWE for now and I think this should be L2 because it is a lower impact issue.