31 Page 31-35 © MAT Journals 2019. All Rights Reserved
A Study on Advanced Cross Site Request Forgery Attacks and its
Prevention
Sahana M P*1, Sonali Joyce Lobo1 1
Assistant Professor 1
Department of Information Science and Engineering, Dayananda Sagar College of Engineering, Bangalore, Karnataka, India
Email:*[email protected] DOI: http://doi.org/10.5281/zenodo.3346240
Abstract
Cross Site Request Forgery (CSRF) is considered as one of the top vulnerability in today’s network where an untrusted website can force the client browser to send the unauthorized valid appeal to the trusted site. Cross Site Request Forgery will let the trustworthiness of the authentic customer.So far, numerous arrangements have been proposed for the CSRF assaults, for example, the referrer HTTP header, custom HTTP header, origin header, customer site intermediary, browser module and random token affirmation. In any case, existing arrangements isn't so insusceptible as to maintain a strategic distance from this assault. Each one of the arrangements is mostly ensured as it were. This study centers around portraying the execution of various conceivable cross site demand imitation strategies and depicting the entanglements in the assortment of preventive systems of cross site demand falsification thus we proposed some barrier instrument to avoid this defenselessness.
Keywords: Cross site request forgery, hidden, one-click attack, sea surf, social engineering, trust, web applications
INTRODUCTION
Nowadays, Internet plays a main role for the business people and for the marketable use. Everyday life becomes easier for the internet user because of the progression in the technologies, but some vulnerability moves the web application to a risky atmosphere. Despite the fact that various web clients get expanded, the assailants also get expanded in parity. So, the security fortune must ends up on account of secure association, resistance personals and money related communicate with those open banks. Point of any organizations is to give an ensured web administration to their customers on account of web condition and to safe gatekeeper the web from the dangers.
In the CSRF attack, the adversary discovers variety of methods to bypass mitigatable techniques. Bypass referrer checks can be performed in two methods.
The first is CRLF (carriage return line feed) vulnerability that allows the http client to unintentionally spoof the headers and the referrer. Second utilizes XSS (cross site scripting) technique. The second technique allows the adversary to specify requests using POST method of web forms. This is as well known as the “HTTP parameter pollution technique". This results in a CSRF attack.
CSRF assault traps the unfortunate casualty to submit invalid and a noxious solicitation. This assault acquires the character and privileges of the person in question. It plays out an undesired activity for the benefit of the person in question. If the user is an authenticated person to the site, the site cannot differentiate between the forged requests that placed by the adversary and a valid request placed by a victim.
32 Page 31-35 © MAT Journals 2019. All Rights Reserved
CSRF misuses the trust that the site has on user. Site tasks are linked to few urls that allowdefinite actions to be performed when the request is placed. If a user has logged in and an adversary tricks the user’s browser into placing a request to one of the urls, the task is carried out as the logged in user. Typically an adversary will implant invalid malicious HTML code into an email to request a definite 'task url'
which executes without the user
information. It is either performed directly or by using a CS Flaw. These attacks are hard to sense. It potentially part a user debating with the company on whether or not the stocks bought the day before it was initiated by the user.
LITERATURE SURVEY
Ramarao R, Radhesh M, and Alwyn R Pais exhibited a customer side intermediary arrangement that identifies and anticipates CSRF assaults utilizing IMG component or other HTML components which are utilized to get to the realistic pictures for the website page. This intermediary can review and modify buyer demands just as the application's answers (yield) consequently and straightforwardly expand applications with the mystery token defense method. William Zeller and Edward W. Felten actualized a customer side program module that can shield clients from specific kinds of CSRF assaults. They executed their apparatus as an expansion to the Firefox internet browser. Clients should download and introduce this augmentation for it to be compelling against CSRF assaults.
Real Time CSRF Hacking
CSRF attack to change DSL router configuration
One moretype of CSRF attack is used to modify the victim’s DSL routers. Many routers all around the universe are configured with default user name and password. Simple img tag can achieve the needed: <img src=http://admin:admin@ipaddress/> <img src=”http:// ipaddress/changeDNS?newDNS=ipaddre ss”/>
Once the DNS is changed, the user can never access the site securely again.
Web Page Attacks
An adversary encompasses a Web page at www.whatsoever.com. This can be any Web page, containing the one that offersprecious services/information that drives traffic to the site. Anywhere on the adversary’s page is an HTML tag that appears as follows:
<img src="http://www.yourwebpage.com/ yourapplication/createuser?email=attacker @attacker.com&type=admin..." height=1 width=1 />
The adversary's page comprises a URL that carries an action on the site. If the user visits the adversary's Web page, the URL is retrieved and the actions are carried out. The attack succeeds as the user is authenticated to the Web page.
PREVENTIONS THAT WON’T
WORK
There are many suggested prevention measures that can be implemented to mitigate CSRF attacks. Some of them, though, are not complete solutions and leave room for the attack to still work. For example:
The use of a secret cookie: This method will not work because all cookies related to the target website will be submitted as usual as in a normal (legitimate) HTTP request.
Accept POST requests only: This suggestion falls short because attackers can deceive an end-user to submit a forged POST request unknowingly using social engineering methods.
URL rewriting: An incomplete solution since some session information is included or exposed in the URL.
33 Page 31-35 © MAT Journals 2019. All Rights Reserved HTTPS - HTTPS does nothing to
defend against CSRF.
HOW TO PREVENT IT AND STAY SECURE?
A well known suggestion to prevent CSRF involves attach non predictable tokens to each request. A prime fact is to state that this challenge token must be linked with user session; else which an adversary might fetch a valid token and make use of it in an attack.
Configuration Overview
To secure back-end servers from CSRF attacks, two lists of items are created:The first list secures against CSRF attacks, and a second list comprises the URLs found in the requests.
For every request received by FortiWeb from the list, it embeds a javascript in the web page. Script runs in the client's browser and appends the parameter tknfv (the anti-CSRF token) to any HTML link elements that have the href attribute (<a href>) and HTML form elements. Subsequent requests that these HTML elements generate contain the tknfv parameter. The parameter has the value of the cookie issued by FortiWeb session management.
The URL list comprises URLs that expect to contain s the tknfv parameter. When these URLs appear in requests without the tknfv parameter, FortiWeb performs the action that is specified in the CSRF protection rule by user.
Use of Tokens
A prevention measure could be the implementation and inclusion of tokens in a user’s (current) session. Tokens are long cryptographic values that are difficult to guess. These will be generated when a user’s session begins and will be associated with this particular user’s session. This challenge token will be
included in each request, which will be used by the server side to verify the legitimacy of the end-user’s request. In order for an attacker to forge a HTTP request, they would have to know the particular challenge value (token) of the victim’s session. The disclosure of the challenge token in the URL (GET requests) should be done wisely and with awareness of the CSRF attack.
Challenge tokens can be used in the View State option of the ASP.NET. Since, it is possible for an attacker to obtain or guess the parameter values of a ViewState then the inclusion and use of a token can make the ViewState unique and protected from CSRF attacks.
Moreover, tokens can be used in the submission of double cookies. The server-side will generate a strong random value which will be included in the submitted cookie on the user’s machine. This will act as the session ID. On sending a POST request, the website will require the particular session ID to be included as a hidden value in the submission form and be included in the cookie as well. If the two values are the same, the POST request will be considered as valid and submitted successfully. Therefore, even if the attacker is able to include any value in the form, based on the same-origin policy, the attacker will not be able to retrieve or modify the token value in the cookie and launch a CSRF attack unless they manage to guess the session ID value.
Other Security Measures
Another prevention measure is the use of challenge-response options. Despite the fact that this measure affects the user experience, it can strongly defend against CSRF attacks.
Furthermore, users should be made aware of potential threats. For example, users should:
34 Page 31-35 © MAT Journals 2019. All Rights Reserved Log out from web applications when
they have finished using them.
Use the web browser with safety – that means making sure not to save any login credentials on the web browser and using legitimate and secure browser extensions.
Finally, you should scan your website using a web vulnerability scanner to detect any Cross-Site Request Forgery vulnerabilities so you can fix them before they cause any issues.
Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:
Logoff the web pages after utilizing a web application.
Do not enable the program to spare username/passwords, and don't enable destinations to "recall" the sign in subtleties.
Do not utilize a similar program to get to delicate applications and to surf openly the Internet; on the off chance that it is important to do the two things at a similar machine, do them with isolated programs.
CONCLUSION
Cross Site Request Forgery is one of the top vulnerabilities in the network. It remains challenging for the researchers to provide an improved solution for mitigating this attack. There are many organizations which were affected by this cross site request forgery attack. Defense mechanisms and offered solutions for cross site request forgery are working in some extend only. There are no defense mechanisms and developers should be careful on scripting pages that take action based upon a user-supplied parameter. A possible thing is to insert an in-between authentication page before taking the action, to be sure that the intended user can call the page. It includes reducing the idle
session time out and taming users to sign out their active session.
REFERENCES
1. A.Barth, C.Jackson, J.C.Mitchell (Oct. 2008), “Robust defenses for cross site request forgery”, In Proc. ACM Conference on Computer and Communications Security (CCS). 2. Cross-Site Request Forgery.
www.owasp.org/index.php/CrossSite_ Request_Forgery, May 2009.
3. J. Burns. (2005), “Cross site reference forgery: An introduction to a common web application weakness”, http://www.isecpartners.com/document s/XSRF_Paper.pd f.
4. M. Johns, J. Winter (May 2006), “RequestRodeo: Client side protection against session riding”, In Proc. of the OWASP Europe Conference, Leuven, Belgium.
5. Mohd. Shadab Siddiqui, Deepanker Verma (2011), “Cross site request forgery: A common web application weakness”, IEEE Conference and White Paper.
6. Nenad Jovanovic, Engin Kirda, Christopher Kruegel (2006), “Preventing cross site request forgery attacks”, IEEE International Conference on Security and Privacy in Communication Networks (SecureComm).
7. OWASP (2001), “Top ten most critical web application security vulnerabilities”,
https://www.owasp.org/index.php/Top
_10 _2013-
Top_10.Forgeries.www.securityfocus. com/archive/1/19S 90.
8. Ramarao R. (May, 2009), “Tool preventing image based CSRF attacks”.
http://isea.nitk.ac.in/rod/csrf/PreventIm ageCSRF/.
9. Sooel Son, “Prevent Cross site Request
35 Page 31-35 © MAT Journals 2019. All Rights Reserved
userweb.cs.utexas.edu/~samuel/PCRF/ Final_PCR F_paper.pdf.
10. Tatiana Alexenko Mark Jenne Suman Deb Roy, Wenjun Zeng (2010), “Cross site request forgery: attack and
defense”,In Proc. IEEE
Communications Society (CCNC).
11. W. Zeller, E. W. Felten (2008), “Cross site request forgeries: exploitation and prevention”, Technical Report, Princeton University.
Cite this article as: Sahana M P, & Sonali Joyce Lobo. (2019). A Study on Advanced Cross Site Request Forgery Attacks and its Prevention. Journal of Web Development and Web Designing, 4(2), 31–35. http://doi.org/10.5281/zenodo.334624 0