Friday 4 September 2015

Prevention Techniques: Cross-site request forgery (CSRF)

1. The best defense against CSRF attacks is unpredictable tokens, a piece of data that the server can use to validate the request, and which an attacker can’t guess. For example, an important request could contain a digest of the user’s session credential, which is different for every user. And, for a little extra security, add a timestamp to the token, to limit the window of opportunity, as shown in the POST body below:
  
POST http://fictitiousbank/transfer.cgi HTTP/1.1 
Host: fictitiousbank 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 
Firefox/3.6.2 
Cookie: PHPSESSIONID=7757ADD8766d455NFJJ23875JBJKBFR from=35367021&to48412334&amount=5000&date=05072010&token=40E03EF45T443W20K4IC567HY4334DD44&timestamp=1184001456 
   
The tokens used should also be cryptographically very strong. 
2. Challenge-Response
Challenge-Response is another defense option for CSRF. The following are some examples of challenge-response options.
  • CAPTCHA
  • Re-Authentication (password)
  • One-time Token
While challenge-response is a very strong defense to CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions 
3. Limit the time for which the user’s credentials are valid. By enforcing inactivity timeouts, you reduce chances of CSRF attacks. 
4. Password re-verification should be given priority over single-sign on. In this method, the users must type in their passwords again when accessing particularly critical functions.
5. Client/User Prevention
Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:
  • Logoff immediately after using a Web application
  • Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
  • Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
  • The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.


Thursday 3 September 2015

Cross-site request forgery (CSRF)

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF . Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.
Example Cross-site request forgery
I just bought a new home wireless router. Like most wifi routers, it’s configured through a web interface. The router was shipped to me with an internal IP address of 192.168.1.1. I’m having trouble configuring the router though, and fortunately the folks over at somemalicioussite.com have published a guide that shows me exactly what buttons to click in the router interface to get everything set up securely. The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.
As I clicked through the configuration guide, I missed the 1x1 pixel image that failed to load:
<img src=”http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89” alt=”pwned” height=”1” width=”1”/>
The attackers knew that when I was reading their tutorial, I would be logged into the router interface. So they had the CSRF attack set up in the tutorial. With that request, my router would be reconfigured so that my traffic will be routed to their proxy server where they can do all manner of bad things with it.
Difference between CSRF and XSS
The fundamental difference between CSRF and XSS is that cross-site scripting (XSS), is designed to exploit the trust the user has for a particular site whilst CSRF aims to exploit the trust that a website has in the visitor’s browser
Tools to test Cross-site request forgery
WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
Cross Site Requester http://yehg.net/lab/pr0js/pentest/cross_site_request_forgery.php
In the next part of this article we will discuss about the Prevention from Cross-site request forgery (CSRF)

Wednesday 2 September 2015

Missing Function Level Access Control

When developers create web interfaces, they have to restrict which users can see various links, buttons, forms, and pages. Developers usually get this right because it is very visible. Unfortunately, making it pretty doesn’t make it secure. Developers often forget that they also have to put access controls in the business logic that actually performs business functions.
Example Missing Function Level Access Control
On my bank’s website, the clerk has a link in his navigation bar to manage the client accounts. The client can’t see that link because clients are not allowed to access this section. But the item in the menu exists in the code, it is simply hidden dynamically using a Javascript function. By analyzing the HTML code, an attacker can easily find the URL to the account management section. And as the access to this section is not controlled, thus the attacker can steal a lot of sensitive data (personal information, account data). Moreover, functions available in that account management section for clerks is not controlled either. The attacker can then transfer money to his own account. And hopefully, the attacker’s actions are not logged.
Attack Vectors Missing Function Level Access Control
Authorized user changes a URL or parameter to a privileged function.
Anonymous users could access private functions that aren’t protected.
Possible Consequences Missing Function Level Access Control
Compromised user accounts.
Compromised administrative accounts.
Unauthorized use of privileged Functionality.
Prevention Missing Function Level Access Control
Implement checks in the controller or business logic.
Don’t hard code and Audit
Deny all access by default, requiring explicit grants to specific roles for access to every function


Prevention Techniques: Cross-site request forgery (CSRF)

1. The best defense against CSRF attacks is unpredictable tokens, a piece of data that the server can use to validate the request, and wh...