one of top vulnerability in todays web applications is Cross Site Request Forgery, where an untrusted website can force the user browser to send the unauthorized valid request to the trusted site. Therefore CSRF impersonates a legitimate user and exploits the trust that the website has for him/her. So far many solutions have been proposed for the CSRF attacks such as referrer HTTP Header, Custom HTTP header, Origin Header, client site proxy, Browser plug-in and Random Token Validation.Â But existing solutions is not so immune as to avoid this attack. All the solutions are partially protected only. This paper proposed a new solution for the attacks using Intrusion Detection System.
Here, Cross site request forgery attack is 5th position in this list. This attack is severe vulnerability in web applications. According to rsnake, founder of ha.ckers.org, there are too many CSRF vulnerabilities on the Internet. The CSRF attacks are typically as powerful as a user, i.e. any action that the user can perform can also be performed by an attacker using a CSRF attack. Consequently, the more power a site gives a user, the more serious are the possible CSRF attacks. For example, if the victim account has administrator rights, this can compromise the entire web application.
In current web environments, many companies have tried to provide safe web services for customers and protect them from the web threats. The web has become an indispensable part of our lives. Unfortunately, as our dependency on the web increases, so does the interest of attackers in exploiting web applications and web-based information. There are more number of attacks which exploits the web application and integrity of the web users. The web browser is a major application used to access webmail's, online banking, community websites, search engines, specific business applications for each sector, etc. from the private network or from Internet. They may contain sensitive information and it required an authentication step, or in the opposite to be accessible to everyone. But all of them can be accessed from a browser using standard protocols.
The general class of cross site request forgery (XSRF) attacks was first introduced by Peter W. in a posting to the BugTraq mailing list, and it has since been picked up by web application developers. Cross site request forgery is defined as "A untrusted website can force the user browser to send the un authorized valid request to the trusted site". This is can be done by without the knowledge of users. It is a new class of attack on web applications which exploit the trust of authenticated users. By launching a successful CSRF attack against the authenticated user, an attacker is able to initiate arbitrary HTTP requests using the user credentials to the vulnerable web application. A successful CSRF attack effectively bypasses the underlying authentication mechanism and it can compromise the end user data and operation. If the victim account has administrator rights, this attack can compromise the entire web application.
CSRF exploits the HTTP protocol's feature, that a webpage can include HTML elements that will cause the browser to make requests to other websites. Like all HTTP transactions, the requests to the other sites will include the user's session information such as cookies or HTTP integrated authentication if they have an established session. Regardless of if the user has a session with the other sites, elements of those sites will be loaded in the victim's browser and can appear in the browser's cache and history. A CSRF can occur on an HTTP request using either the GET or the POST method. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.
CSRF attack can be carried out in different ways. The attack could be done using a HTML IMG Tag or a specially crafted URL embedded into the Target application. This works for sure since the victim will be logged into the application. Another way of doing it is to host a site/blog and influence the victim to visit the site. Many sites can be used to host a CSRF including online forums (which often allow a user to link to an image as an attachment), HTML email, photo galleries, wikis, blogs, online auctions, and E-Commerce sites. CSRF attack using these sites might not work always as users may not be currently logged into the target system when the exploit is tried. CSRF flaws exist in the web applications with a predictable action structure and which use the above credentials to authenticate users. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish a malicious request from a legitimate user request.
Cross Site Request Forgery vulnerabilities can be divided into two major categories:
Stored CSRF: A stored CSRF vulnerability is one where the attacker can use the application itself to provide the victim the exploit link or other content which directs the victim's browser back into the application, and causes attacker controlled actions to be executed as the victim. If the application is vulnerable to CSRF, an attacker can store the malicious code using IMG, IFRAME tag or XSS in a field that accepts HTML. If the attacker can store a CSRF attack in the site, the severity of the attack is high. The likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. Stored CSRF vulnerabilities are more likely to succeed, since the user who receives the exploit content is almost certainly authenticated to perform actions. Stored CSRF vulnerabilities also have a more obvious trail, which may lead back to the attacker.
<form action=https://example.com/fn?param=1 method="get">
<a href="https://example.com/fn?param=1">click here</a?
Reflected CSRF: In reflected CSRF vulnerability, the attacker uses a system outside the application to expose the victim to the exploit link or content. This can be done using a blog, an email message, an instant message, a message board posting, or even an advertisement posted in a public place with an URL that a victim types in. Reflected CSRF attacks will frequently fail, as users may not be currently logged into the target system when the exploits are tried. The trail from a reflected CSRF attack may be under the control of the attacker, however, and could be deleted once the exploit was completed.
Auto posting Forms
<form method="POST" action="https://example.com/fn">
<input type="hidden" name="sp" value="8109"/>
REAL WORLD EXAMPLES
1. ING Direct (ingdirect.com)
A vulnerability on lNG's website that allowed additional accounts to be created on behalf of an arbitrary user. Some of the people were able to transfer funds out of users' bank accounts. This was the first CSRF vulnerability to allow the transfer of funds from a financial institution
2. YouTube (youtube.com)
CSRF vulnerabilities were discovered in nearly every action a user could perform on YouTube. An attacker could have added videos to a user's "Favorites," added himself to a user's "Friend" or "Family" list, sent arbitrary messages on the user's behalf, tlagged videos as inappropriate, automatically shared a video with a user's contacts, subscribed a user to a "channel" (a set of videos published by one person or group) and added videos to a user's "QuickList" (a list of videos a user intends to watch at a later point).
3. MetaFilter (metafilter.com)
Vulnerability existed on Metafilter that allowed an attacker to take control of a user's account. A forged request could be used to set a user's email address to the attacker's address. A second forged request could then be used to activate the "Forgot Password" action, which would send the user's password to the attacker's email address
4. The New York Times (nytimes.com)
A vulnerability in the New York Time's website allows an attacker to find out the email address of an arbitrary user.This takes advantage of the NYTimes's .. Email This" feature, which allows a user to send an email about a story to an arbitrary user. This emails contains the logged-in user's email address. An attacker can forge a request to active the "Email This" feature while setting his email address as the recipient.When a user visit's the attacker's page, an email will be sent to the attacker's email address containing the user's email address. This attack can be used for identification (e.g., finding the email addresses of all users who visit an attacker's site) or for spam. This attack is particularly dangerous because of the large number of users who have NYTimes' accounts and because the NYTimes keeps users logged in for over a year.
Also, TimesPeople, a social networking site launched by the New York Times on September 23, 2008, is also vulnerable to CSRF attacks.
5. Gmail ( www.gmail.com )
A vulnerability in GMail was discovered in January 2007 which allowed a attacker to steal a GMail user's contact list. A different issue was discovered in Netflix which allowed an attacker to change the name and address on the account, as well as add movies to the rental queue etc
It was discovered in Nettlix which allowed an attacker to change the name and address on the account, as well as add movies to the rental queue etc.
As a striking example, in Feb 2008,Korea's most popular eBay's site, Auction, was hacked by a CSRF attack; 18 million people'spersonal information were revealed on the internet due to this attack
It is a policy that needs to be adopted by developers and users to avoid this attack in some extend.
1. Use random tokens: To defend against the CSRF attack it is one of the greatest mechanisms. Form proposal was done during the use of random tokens at all time. To fill in malicious URL, predicting of next random pattern was difficult for the aggressor.
2. Use of post in form rather than get: Form submission involves two methods they are get and post. Form submission is the secure one for post method. Variables and values in URL are understood by anyone in get method as a query strings.
3. Limiting the lifetime of authentication cookies: Beside CSRF it is a durable deterrence. At a short period of time lifetime was limited. After a short period of time cookies will be terminated when the user moves to further web site. For any action user involves in re-login. Re-submission of password by the user was not done if the attacker tries to send any HTTP request.
4. Damage limitation: To reduce the damage from CSRF those steps are followed by the Destruction restriction. To perform CSRF by an attacker on a website an authentication was required for every usage to limit the damage.
5. Force user to use your form: Force the user always to use the form of website. For this purpose a hidden fields are used which a helpful one. It is one of the protection and easy to bypass
6. Auto log off: If a user moves to some other site (untrusted) means it will automatically log off. So again the user wants to login.
7. Don't start new task while sensitive task running: If the user is using sensitive task means don't start new application or task (untrusted).
8. Never store the password to anywhere: The user should never store the password in anywhere or any place.
9. Single login access at a time: A user should use single login access. If more than one access is present means it will intimate to the user.
10. Divert to some other page (honeypot): If the user or system find any malicious activities means it will automatically divert to some other page.
SOME OF THE TOOLS ARE:
â€¢ OWASP CSRF Tester
Cross site request forgery (CSRF) attacks was first introduced by Peter W in a posting [ ] to the BugTraq mailing list, and has since been picked up by web application developers . Nanad jovanovic et.al proposed a mitigation mechanisum for CSRF that provides only partial protection by replacing GET requests by POST requests or relying on the information in the Referer header of HTTP requests.
Navad jovanovic also proposed a solution that provides a completely automatic protection from XSRF attacks. More precisely, his approach is based on a server-side proxy that detects and prevents CSRF attacks in a way that is transparent to users as well as to the web application itself. (Orthogonal proxy).
Johns and Winter introduced RequestRodeo,a client side solution to counter this threat. With the exception of client side SSL, RequestRodeo implements protection against the exploitation of implicit authentication mechanisms. This protection is achieved by removing authentication information from suspicious requests. They proposed a client side solution to enable security conscious users to protect themselves against CSRF attacks. Their solution works as a local proxy on the user's computer [ ].
Burns and Schreiber provide comprehensive introductions to CSRF attacks. To prevent the CSRF attack, they used following methods. Use cryptographic tokens to prove the Action Formulator knows a session specific secret, use secret tokens to prove the Action Formulator knew an Action and user specific secret, use the optional HTTP referrer [sic] header to verify Action Formulators, require changes to application state to be done only with HTTP POST operations and use a simplified CSRF Prevention Token.
Drawback of their proposed work is that the attackers can adjust their attacks to be form based like CSRF, Submit forms automatically or though tricking users by making huge, mislabeled submit buttons. The header is optional and may not be present, some browsers disable this header and it is not available when interactions occur between HTTPS and HTTP served pages. The risk of header spoofing exists, and tracking the valid sources of invocations may be difficult in some applications.
William Zeller and Edward W. Felten implemented a client side browser plug-in that can protect users from certain types of CSRF attacks. They implemented their tool as an extension to the Firefox web browser. Users will need to download and install this extension for it to be effective against CSRF attacks. Their extension works by intercepting every HTTP request and deciding whether it should be allowed. This decision is made using the following rules. First, any request that is not a POST request is allowed. Second, if the requesting site and target site fall under the same-origin policy, the request is allowed. Third, if the requesting site is allowed to make a request to the target site using Adobe's cross-domain policy, the request is allowed. If their extension rejects a request, the extension alerts the user that the request has been blocked using a familiar interface (the same one used by Firefox's popup blocker) and gives the user the option of adding the site to a white list.
Ramarao R, Radhesh M, Alwyn R Pais was presented a client-side proxy solution that detects and prevents CSRF attacks using IMG element or other HTML elements which are used to access the graphic images for the webpage. This proxy is able to inspect and modify client requests as well as the application's replies (output) automatically and transparently extend applications with the secret token validation technique[ ].
Tatiana Alexenko et.al were developed a Mozilla extension that integrates with the Firefox web-browser to protect the user's browsing history. The extension generates HTTP requests to random URLs from the user's browsing history. The extension allows the user to specify how often the requests get sent as well as giving users the option of adding a random URL to the Referrer field of the extension-generated HTTP request. The latter option is bound to initiate discussion, because the pairing of the requested URL and Referer is random which can lead to combinations that should not exist during normal browsing. This can affect online advertising and raise red flags for web administrators.
They implemented a client-side defense measure that previews the HTML code before each page load and detects potential CSRF attacks. The detector would first find all form tags and check the "action" attribute of the "form" tags for deep linking. If such forms are found, the CSRF detector will prompt the user if they want to add the pairing of the URL of the website the code is located on and the URL of the form action to a white list.
Sooel Son was proposed PCRF is a dynamic token generating defense scheme against CSRF. PCRF's basic goal is to prevent CSRF attacks by adding a fresh token to every web request whose target page should be protected one way to efficiently prevent CSRF attacks toward PHP web applications. This defense system is called PCRF: Prevent Cross-site Request Forgery attack. PCRF provides an automatic robust solution again CSRF threats by using a CSRF token. Due to the property of cryptographically secure hash function. It used to verify whether the token has been previously issued from servers.
Table Type Styles
It may sometime Crushed.
May be Some user aware of this plug-in.
Clint Side Proxy
Random Token Validation
Example of a figure caption. (figure caption)
Intrusion Detection system.