The Protocol is Secure Against CSRF, But You Need to Consider It
From The Socknet
What is CSRF?
- CSRF
- Cross-Site Request Forgery. Somewhat of a misnomer for code that takes advantage of a user's permissions on a website to cause him to make a request he did not intend to make. This code may exist on an attacker's website (thus the "Cross-Site"), or it may be injected into a victim's website (this increases the chance that the victim will see it and run it).
Although CSRF and XSS both have "Cross-Site" in their names, CSRF attacks cannot be filtered like XSS attacks, they must be protected against on the receiving end of the attack.
Example: http://www.example.com/forum may contain the following message post from an anonymous user:
Hi everybody, lol at this cat! <img src="http://www.example.com/delete_user?name=poor_joe&verified=1" />
In this example, most users will only notice that the image is broken. Someone will call an admin to come delete the broken picture. The moment the admin attempts to view the message, his browser will make a request to a web address which will delete the user with the name "poor_joe".
Assuming the admin had the power to delete the user, the user is now gone. The attacker has done his dirty work without obtaining any passwords or cookies.
Plus, it looks like this link is built to bypass any verifications that the admin would normally see before deleting a user.
Notice that this same attack could be run by convincing the admin to visit an entirely different website. In fact, if the attacker has control of the website which runs the attack, he may be able to form an even more powerful attack.
The only way to avoid this problem is to require forms to include a hidden field with a special code based on unobtainable information about the user, such as session information. This code may be the user's SessionID, or for security, may be random or a hash of the session information. Session information, normally stored in cookies, is invisible to an attacker*.
Note: this problem is not restricted to administrators. In the example above, poor_joe may have the power to delete his own account, so he would have the same results if he attempted to view the image.
* There are two ways that an attacker could obtain a user's session information:
- through a successful XSS attack
- through session injection, which exploits a weakness in some browsers allowing an attacker to set cookies on an separate website. The attacker would know the session information, because he set it himself.
If either of these attacks is available, then the attacker need not waste time attempting CSRF attacks. If he has the session information, then he could just use it to attack directly. So the mechanism described here to protected against CSRF is no less valuable.
CSRF on the Socknet
CSRF no longer affects Socknet intercommunication. This section will remain for a little while, just to make that point.
However, CSRF weaknesses must still be avoided in the user interfaces of Socknet providers and services. As stated in XSS Sanity, it won't help the Socknet to get a reputation as easily hackable.
