Ultra-large Cookie Denial of Service Attack
Have you ever wondered what will happen if the website has a very large Cookie?
Not to mention, try it out immediately:
for (i = 0; i < 20; i++) document.cookie = i + '=' + 'X'.repeat(2000)
What is an error reported on the website?
As we all know, cookies are inserted in the request header. If there are too many cookies, it is clear that the entire HTTP header will be extended.
However, in reality, almost all servers limit the length of the request header to avoid malformed packets consuming server resources.
The interesting thing is that cookies can be stored for a long time, so as long as they do not expire, the corresponding site will never be accessible!
Believe it? Click here to try (
Warning users who do not clear cookies should be cautious)
Why! Because the blog garden supports custom dress-up, users can embed their own scripts. As a result, once the prank script is executed, the site Cookie is contaminated, and the whole website cannot be accessed!
Based on this principle, we continue to explore Cookie-related attributes to improve attack performance.
ExpiresCookie is permanently stored thanks
expiresThis expiration value.
Theoretically, the Cookie expiration time can be long enough. However, in view of the actual situation, it may take up to a few months.
But for the Internet, this is also very long. Who can tolerate the inability to use a website for several months?
Therefore, we can set a long enough expiration time-as long as the user does not actively clear the Cookie, the corresponding site will never be accessible!
Domain, such as the blog site, all users are under www.cnblogs.com. In addition to this main station, can other sub-station services be damaged together?
The answer is yes! Because Cookie has a special attribute
domainWhich allows the sub-site to set the Cookie of the parent site. It can even be the root domain!
Therefore, the pages of www.cnblogs.com can be written into the cnblogs.com domain with a large Cookie.
In the future, as long as users access * .cnblogs.com resources, all of them will become 400.
This feature can be exploited to XSS attacks. As long as any sub-site of a website can run cross-site scripts, attackers can block the website! (GFW: Better than me ~)
Path is not a good choice. Especially in the past few years, everyone has some knowledge about the network and how to clear the cache. Many users will try it.
Therefore, in order to keep a low profile, we do not block the page, so as not to be detected by users too early.
We only SHIELD Special URLs, such as AJAX request interfaces. In this way, the page can still be opened normally, but some operations in the later stage always prompt failure. Therefore, most users will think that the website has a problem and will not doubt the cause.
To more accurately control the Cookie granularity,
pathThe attribute can be used. For example, we only contaminated the/mvc/vote/VoteComment. aspx page of the blog Garden:
for (i = 0; i < 20; i++) { document.cookie = i + '=' + 'X'.repeat(2000) + ';domain=cnblogs.com; path=/mvc/vote/VoteComment.aspx'
In this way, the page can still be viewed normally, but the "like" function is blocked:
Is it interesting :)
The effect of local shielding is obviously more confusing.
Protocol
Carefully review the Cookie attributes,
secureNo more attributes related to URL Scheme.
This means that both HTTP and HTTPS cookies are shared. Therefore, we can block HTTPS sites under HTTP!
However, XSS does not have to be available, but under special conditions, any site can have XSS-that is, when traffic is hijacked.
When a user's traffic is hijacked, the man-in-the-middle can simulate any HTTP site, so that the Cookie can be set for any site:
When you open any HTTP page, inject scripts into it.
Then, create a hidden frame page for the target site, and the man-in-the-middle will return the specific page content. The script can modify the Cookie of the target site.
Next, let's try it.
Through proxy, we simulate the scenario where traffic is hijacked. When any page is opened, release DeBuff for the target site:
Home Page implementation:
Target framework page implementation:
You can modify the cookies of the target site in batches through a bunch of frame pages.
Finally, switch back to the normal network and find that the evil halo is still in effect:
Even the encrypted HTTPS site is not spared:
A new method is available for man-in-the-middle cache attacks!
The purpose may be something you want to talk about. Is this not only a prank, but also practical.
However, as long as you give full play to your imagination, you can still play with some interesting results. For example, in combination with XSS:
Shield the data modification page to prevent users from changing their passwords
Shield the logout interface to keep the user session from expired
Shield the management background and make the Administrator unable to operate
Or traffic hijacking:
Shield front-end security scripts to prevent page jumps
Update websites for shielding programs and patches, etc.
Summary
Of course, this so-called "Denial of Service" is just a local deception, and it has no impact on real servers.
Although not as effective as traditional attacks, this method is more civilized. Only some people and even some functions are attacked, without interfering with other users.
