Académique Documents
Professionnel Documents
Culture Documents
Submit Tips
Search
HOME
REVIEWS
HOW-TOS
CODING
INTERVIEWS
FEATURES
OVERVIEW
BLOGS
SERIES
IT ADMIN
Search for:
Search
Intended for information security experts, systems administrators, and all those concerned about Web security, this third article in the series moves on from SQL injection and XSS to how to secure Web applications against Cross-Site Request Forgery attacks. I once again stress that neither LFY nor I aim to teach readers how to attack servers. Rather, the attack techniques are meant to give you the knowledge that you need in order to protect your own infrastructure.
Cross-Site Request Forgery (CSRF, a.k.a. XSRF, one-click attacks, session riding, confused deputy, client-side Trojan, hostile linking, automation attack or sea surf) is a client-side Web application attack, where an attacker exploits implicit authentication mechanisms to force an end user to execute unwanted actions in an authenticated Web application. CSRF is a non-avoidable dangerous security risk, and its constant 5th position in OWASPs Top 10 most critical security risks for the past three years, underlines this fact. A little social engineering (for example, through email or IM) is all it needs to trap a victim into unwittingly executing actions of the attackers choice. A successful CSRF exploit can compromise end-user data and operations, when it targets a normal user. If targeted at an administrator account, the attack can compromise the entire Web application. The word CSRF itself means that the attack is done using a cross-site request; its forged because its invisible to the user. A cross-site request is one where a page loaded from one website makes a request to another site for resources that are part of the page (like images, for example). While its easy for a malicious site to have such HTML code in its pages, such crosssite requests can also be caused by viewing bulletin boards, forums, or social networking sites (for example) where users are allowed to post images with foreign URL sources that is, the images are hosted on other sites. CSRF attacks are effective in situations which meet the following criteria: The victim has an active session on the target site. The victim is authenticated by implicit authentication mechanisms (like cookies or HTTP authentication) on the target site. The main aim of a CSRF attack is to perform an action against the target site using the victims privileges in a properly authenticated session. The key requirement is prior access to, and knowledge of the Web applications valid URLs, by the attacker. In a typical CSRF attack, the attacker creates a hidden HTTP request inside the victims Web browser, which is executed in
Follow
+2,512
Scenario 1
Find us on Facebook
Assume the victim is logged in to his online bank account, and is using the money transfer feature. The banks site uses cookies (implicit authentication) to authenticate logged-in user sessions. After filling out the money transfer form, when the Submit/OK/Transfer button is clicked, the victims Web browser issues an HTTP request to the banks Web server, to perform the transfer. Heres what the request looks like when using an HTTP POST request:
Comments
Tag cloud
Note: The attacker can obtain the HTTP request/response data transmitted to/from the Web server in multiple ways: using free services offered by sites like web-sniffer.net and httpsniffer.com, or by using local network sniffers on their LAN while they use the banking site themselves. Examining the captured requests and responses lets them determine the valid URLs for the Web application. Now assume that the victim, while still logged in to the online banking site, opens another tab/window in the same browser, for a malicious site (lets call it w w w . a t t a c k e r . c o m ). This could be due to clicking on a malicious link sent to the victim via IM or email. Such a link might take the victim to h t t p : / / w w w . a t t a c k e r . c o m / c h e c k t h i s o u t . h t m l , which contains the following malicious HTML code:
< H T M L > . . < I M GS R C = " h t t p : / / f i c t i o u s b a n k / t r a n s f e r . c g i ? f r o m = 3 5 3 6 7 0 2 1 & t o 4 8 4 1 2 3 3 4 & a m o u n t = 5 0 0 0 & d a t e = 0 5 0 7 2 0 1 0 " . . < / H T M L >
When the victims browser loads this page, it will try to display the specified zero-width, zeroheight (thus invisible) image as well, by making a request to the URL specified in the
s r c attribute. Since the customer is still logged in to the banking site, an amount of 5,000 from
account 35367021 will be transferred to account 48412334, which could belong to the attacker. The bank site sees this request as completely legitimate, since the browsers session cookie tells it that the user authenticated himself with the correct credentials! The attack above is depicted in Figure 1.
To prevent wary users or someone accidentally stumbling across the CSRF URL as the image source (if they view the source HTML of the page), the URL could be obfuscated as a seemingly innocent HTTP request. The attacker could make it look like a valid image URL such as < i m g s r c = " h t t p s : / / w w w . a t t a c k e r . c o m / p i c t u r e 1 . g i f "w i d t h = " 0 "h e i g h t = " 0 "/ > . Here,
when this request for p i c t u r e 1 . g i fis received, a t t a c k e r . c o muses the HTTP redirect mechanism to redirect the browser to a different URL. That different URL is the Web application state-changing URL like the money-transfer action URL in this scenario. The attack method above (i m gs r c ) could be used if the Web application uses HTTP GET to submit requests. If it uses HTTP POST instead, then the attacker can use a hidden i f r a m e containing an HTML form, plus JavaScript that submits it to the bank site, like this snippet:
< f o r mn a m e = " b a d f o r m "m e t h o d = " p o s t "a c t i o n = " h t t p : / / f i c t i t i o u s b a n k / t r a n s f e r . c g i " > < i n p u tt y p e = " h i d d e n "n a m e = " f r o m "v a l u e = " 3 5 3 6 7 0 2 1 " > < i n p u tt y p e = " h i d d e n "n a m e = " t o "v a l u e = " 4 8 4 1 2 3 3 4 " > < i n p u tt y p e = " h i d d e n "n a m e = " a m o u n t "v a l u e = " 5 0 0 0 " > < i n p u tt y p e = " h i d d e n "n a m e = " d a t e "v a l u e = " 0 5 0 7 2 0 1 0 " > < / f o r m > < s c r i p t > d o c u m e n t . b a d f o r m . s u b m i t ( ) < / s c r i p t >
The CSRF attack using the HTTP POST method is summarised in Figure 2.
Please note that this scenario was used just to explain CSRF clearly, and that no bank is careless enough to let such an attack happen. I reiterate that you should not try any of these steps on any public server.
Scenario 2
Another CSRF attack scenario exploits the firewall Web management system. This is again based on session cookies. Lets suppose the firewall Web management application has a function that allows an authenticated user to delete a rule, specified by its positional number, or all the rules of the configuration, if the user enters *. For example, a valid URL to delete a single rule, number 5, would be: h t t p : / / w w w . e x a m p l e . c o m / f i r e m a n g e / d e l e t e ? r u l e = 5 Malicious HTML for the CSRF, using HTTP GET is as follows:
< H T M L > < I M GS R C = " h t t p : / / w w w . e x a m p l e . c o m / f i r e m a n g e / d e l e t e ? r u l e = 5 "w i d t h = " 0 "h e i g h t = " 0 " > . < / H T M L >
Scenario 3
Routers for private use, like popular DSL routers, come with a preconfigured IP address for the LAN interface (e.g., 192.168.0.1), which most users do not change. Thus, the host-part of the URL is known in most cases. Attackers are familiar with the workings and URLs of most popular routers, and if they can social-engineer the victim into clicking a malicious link, this will (for example) enable the remote Web management on port 8080, allowing it to be administered from any computer on the Internet. The malicious Web page might contain the following HTML:
< I M GS R C = h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 / e n a b l e _ r e m o t e _ m a n a g e m e n t = t r u e & i p s _ a l l o w e d = * & m g m t p o r t = 8 0 8 0 >
The attacker can also change the routers default account name, and could also compromise
network printers so if you have a DSL/home router left at its default settings, change the preconfigured IP and default passwords right now! Using well-known URLs for Web applications, an attacker can also reset your Web-based account passwords, tamper with your corporate Web mail, and delete or modify accounts in Web applications. CSRF is a serious vulnerability, and cannot be taken lightly.
Cookies:Web browser cookie technology provides persistent data storage on the client side, which is often used by todays Web applications to store authentication tokens. After a successful login procedure, the server sends a cookie to the client. Every subsequent HTTP request that contains this cookie is automatically regarded as authenticated. The typical cookie authentication process is shown in Figure 4.
Client-side SSL authentication: The Secure Socket Layer (SSL), and its successor, the Transport Layer Security (TLS) protocol, enable cryptographically authenticated communication between the Web browser and the Web server. To authenticate, X.509 certificates and digital signature schemes are used. What all these schemes have in common is that after a successful initial authentication, tokens are sent automatically in further requests, without asking the user for permission this is what
makes Web applications that use these authentication techniques, vulnerable to CSRF attacks.
perform actions. CSRF is solvable by forcing all sensitive requests over POST while denying GETs. CSRF can be prevented by filtering based on the referrer header. Browser enforcement of Same Origin Policy (SOP) prevents CSRF. Browsers that implement SOP will prevent scripts from accessing the DOM of a page originating from another domain, or accessing cookies that originate from other domains. However, they do not prevent scripts from sending requests to other domains. Furthermore, when a script sends a request to another domain (or when an IMG tags SRC attribute is set to another domain), the browser will execute the request, and will also send any cookies it has that are valid for the domain, along with the request. (See the following highlight on SOP). This option is very unreliable, since attackers can easily block the sending of the referrer header, through the use of certain browser and Flash exploits. Some browsers also omit the referrer header when they are being used over SSL. Moreover, many firewalls and anti-spyware software often drop referrers, in their default mode, without letting users know. But, using referrers can be viewed as another incremental roadblock. While POSTs can be more difficult to exploit, they certainly are exploitable, as shown in Scenario 1. Using POST rather than GET can provide a defense only against local CSRF attacks; POST requests can still be created with hidden IFRAMEs on foreign Web pages. Forms can mislead users about what they are sending, and where, and scripting can lead to automatic submission. JavaScript is fully capable of sending POST requests via form submissions.
Sane Origin Policy (SOP): Web browsers use a security model called the same origin policy (SOP) to enforce some access restrictions on Web applications. The SOP identifies each website using its origin, which is a unique combination of protocol, domain and port, and creates a context for each origin. Two resources are considered to be of the same origin only if all these values are exactly the same.
Attackers simply read the site-generated token from the response, and include that token with a forged request. One such example of this is attackers exploiting an XSS vulnerability of a website to add a fake user with administrator privileges, when the site is secured against CSRF attacks. A good discussion on this type of attack (with code) is available in the Further Reading section at the end of the article. Please do spend some time on it. It was by using an XSS vulnerability that the Samy worm bypassed MySpaces CSRF protection in 2005, infecting over one million accounts within just 20 hours of its release.
Attacking intranets
Exploiting intranets involves CSRF attacks through IP-based implicit authentication schemes. Most intranet Web servers are vulnerable to this type of attack. The fact that many intranet servers continue to use default passwords, leave hosts unpatched, and blindly rely on perimeter firewalls to block external attacks has given rise to intranet vulnerabilities to CSRF and malicious JavaScript. This malicious JavaScript, once behind the firewall, can attack the intranet; since it is independent of the operating system and the Web browser, it is hard to defend against. One such example is port scanning of the intranet Web server, using JavaScript and CSRF. The JavaScript constructs a local (intranet) URL that contains the IP address and the port to be scanned. The script then includes an element in the Web page (such as an image, IFRAME or remote script) that is addressed by the URL. Also, using JavaScript time-out functions, and event handlers like O n L o a dand O n E r r o r , the script can decide whether the host exists and whether the given port is open. If a time-out occurs, the host probably does not exist. An O n L o a devent indicates that the host probably runs a Web server, and an O n E r r o r event indicates that the host exists, but the port is closed. The typical attack scenario is shown in Figure 6.
In this scenario, the attacker forces/convinces the intranet user to visit a malicious page on the attackers server, which contains the following HTML in a hidden IFRAME:
< S C R I P TS R C = " h t t p : / / 2 1 1 . 2 2 4 . 1 9 6 . 1 / " > < / S C R I P T >
As soon as the user executes this page, the information about the existence of the Web server is sent to the attacker in the form of errors. Apart from this, the attacker can fingerprint applications/routers/network devices, and also might locate HTTPS or development servers by varying the ports.
For users
1. Log out of the important Web application when you have completed your work/transactions. Do not open any non-trusted site in the same browser while logged in to the important site. If you need to do this for some reason, use a separate browser for the untrusted site(s). 2. Use Mozilla Firefox with the NoScript addon, which allows JavaScript, Java and other executable content to run only from trusted domains of your choice. It is one of the best
defenses available for protection against XSS, CSRF and click-jacking attacks. Also consider using the CsFire addons, which autonomously protect you against CSRF and other dangerous or malicious cross-domain requests. CsFire will remove authentication information (cookies and authentication headers). 3. Use multiple browsers and segregate your browsing into trusted/sensitive sites/applications and untrusted/less important sites/applications. For example, use Firefox, with the NoScript and Adblock Plus (ABP) addons installed, to browse trusted/sensitive sites/applications. In NoScript, whitelist trusted sites so JavaScript from those sites will work. Set up ABP to block known malicious sites; use the auto-configuration URL at the end of this blog post to add the filter list to ABP. For other (untrusted) sites, install another browser like Google Chrome, Chromium or Opera. If youre not certain about off-site links encountered in trusted sites (e.g., someone mails you a link to your GMail, which you are viewing in Firefox), then instead of visiting it in Firefox, drag the link from the page in Firefox to Chrome/Chromiums tab bar (or copy/paste it), to have it open in a new tab in Chromium. Since only the link URL is transferred to the other browser, and any implicit-authentication tokens remain in Firefox, this is a safer practice. 4. Regularly deleting long-duration cookies (those which are set to expire after an inordinately long time) will also help mitigate the threat. 5. If possible, dont store usernames and passwords in the browsers password manager (for example, see this LWN article).
For developers
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 cant guess. For example, an important request could contain a digest of the users 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:
The tokens used should also be cryptographically very strong. 2. Limit the time for which the users credentials are valid. By enforcing inactivity timeouts, you reduce chances of CSRF attacks. 3. 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. 4. Switching over to URL rewriting is not recommended since, when URLs contain session tokens, the tokens could be leaked via proxy-logs/referrers. Moreover, they are also not very helpful against local/stored attacks, since all URLs produced by the application contain the token. 5. Do not rely (solely) on referrer checking, as techniques exist to selectively create HTTP requests without referrers. 6. For protection against local/stored attacks, you should mirror all foreign content, and dont allow arbitrary URLs in your Web application. Moreover, local attacks can be mitigated if you only serve images from your own servers (like for social sites and forums) and also dont allow users to store arbitrary data on your servers. 7. When building defenses against CSRF, you must eliminate XSS vulnerabilities. 8. Throw as many roadblocks at the attacker as possible, including customised error messages, checks on HTTP referrer headers and Web application firewalls. 9. Use CAPTCHAs, especially for important transactions, to check whether theres a human being at the other end, and not an automated attack. 10. Harden the intranet websites, apply security patches and updates, and change default passwords.
2. RequestRodeo is an HTTP proxy written in Python, using the Twisted framework, OpenSSL and SQLite. It protects its user against CSRF. You can find it here. For more detailed information on CSRF, and more defenses against it, dont forget to visit the Further Reading section below. We will deal with other dangerous attacks on Web applications and Apache in the next article. Always remember: know hacking, but no hacking.
Further reading
Whitepaper called Using XSS to Bypass XSRF Protection secologic project CSRF Prevention Cheat Sheet whitehatsec.com contains good information both on XSS and CSRF and other attacks
Related Posts:
Securing Apache, Part 4: Cross-site Tracing (XST) & Cross-site History Manipulation (XSHM) Securing Apache, Part 5: HTTP Message Architecture Securing Apache, Part 6: Attacks on Session Management Securing Apache, Part 2: XSS Injections Securing Apache, Part 9: Attacks that Target PHP-based Instances
Tags: Adblock Plus, Apache, attacker, authentication mechanisms, bank account, bulletin boards, critical security, Cross-Site Request Forgery, CSRF, dynamic HTML, forgery, forums, Google Chrome, html, HTTP cookie, IM, Internet, IP, IP address, Java, JavaScript, LFY November 2010, malicious site, mozilla firefox, MySpace, Securing Apache series, Security, security risks, social networking sites, SOP, SQL injection, URL, User agent, Web, Web application, web applications, web security, Web server, X.509, XSRF, XSS
Previous Post
Next Post
What's this?
Citizens Over 50 May Qualify to Get $20,500 this Year Moneynews Don't Let Your Kids Read This: Paying Teens for Citi Women & Co. VIDEO: Beyonce Gets a Run for Her Money DailyCandy Lady Gaga Changes Her Fashion Style GLAM
India has immense under-utilised talent in the cloud 42 comments Getting Your First Job Code Sport
1 comment 1 comment
C o m m e n t fe e d
Su b s cri b e vi a e m a i l
Reviews
How-Tos
Coding
Interviews
Features
Overview
Blogs
Search
Popular tags
Linux , ubuntu, Java, MySQL, Google, python, Fedora, Android, PHP, C, html, w eb applications , India, Microsoft, unix , Window s , Red Hat, Oracle, Security , Apache, xml, LFY April 2012, FOSS, GNOME, http, JavaScript, LFY June 2011, open source, RAM, operating systems
All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherw ise noted. LINUX For You is pow ered by WordPress, w hich gladly sits on top of a CentOS-based LEMP stack.