by Kevin Yank
[url=\"http://www.sitepoint.com\"]SitePoint[/url]
With all the ruckus surrounding GET requests being automatically issued by Google Web Accelerator, Web developers have started thinking of other reasons to be careful about choosing between hyperlinks and form buttons. In particular, are POST requests triggered by form buttons inherently more secure than hyperlinks?
In addition to being inadvertently triggered by Web acceleration products like GWA, hyperlinks may be the target of attack. Here\'s the typical play-by-play:
You log into a secure area of your Website. You do what you need to do, and then leave without explicitly logging out.
One way or the other, you are fooled into visiting a page that contains an
Because you are still logged into your site, it will process the request from your browser and take whatever action may be associated with the address without your knowledge or approval.
At first glance, this may seem like another downfall of allowing GET requests to perform sensitive actions in a Web application. Can we protect against such attacks by using form buttons that submit POST requests to perform sensitive actions?
The answer is no, we can\'t. The play-by-play of an attack with a POST request is the same, except for step 2:
You are fooled into visiting a page that contains a hidden form and javascript code that automatically submits it to the secure area of your site.
As long as javascript is enabled in your browser, a form POST is just as easy for an attacker to fake as a hyperlink click.
Both of these attacks fall under the category of Cross-Site Request Forgeries (CSRF), one of the most difficult kinds of attack to predict.
The most practical way to protect against CSRF attacks is to use a formkey to protect sensitive forms in your Web applications. A formkey is a hard-to-guess value (like a short string of random characters) generated on the fly and placed in a hidden field of the form by your Web application. If a form submission doesn\'t include a valid formkey, it\'s simply rejected.
Now I\'ll grant that this sort of protection can be a hassle to implement, but if you\'re at all worried about the security of your Web applications, this kind of thing needs to be on your mind.
As Web developers become less careless about their mistakes, attackers develop their skills in equal measure. In a world where the slightest crack in a browser\'s security makes headlines, Web developers need to do their part to close what can by comparison be gaping holes in website security.
source: [url=\"http://www.sitepoint.com\"]SitePoint Tech Times[/url]
