CSRF stands for cross-site request forgery. It’s also known as session riding or XSRF, when we are browsing a website it requests data from other websites on our site. in example iframe, as you can see on our website where we add videos on the home page which is not stored on our server but it is actually being embedded from video streaming websites such as Youtube. Suppose you have a login page in your website and there is csrf vulnerability so I can easily add your login page in my website and get a request from my website directly, It works by forcing the slave’s browser to run HTTP requests in order to implement a range of actions, for example, Disruption of the normal sequence of the site, Permission faking\stealing, Transfer of funds from the Bank , or get session accept.
CSRF and the way to exploit it is extremely easy; Much easier than all the complicated injections.
How CSRF is Dangerous?
When a website starts requesting the data from another website on behalf of a user, as long as the request is an unauthenticated one, e.g. browser session cookie is not sent, there are no security concerns. so when the user’s session cookie is sent with the request, an attacker can launch a Cross-Site Request Forgery attack, which abuses the trust relationship between the victim’s browser and the server-side.
Requirements to exploiting CSRF.
- Make sure that the slave has SESSION \ COOKIE on the target site.
- the slave must be identified by the network protocol verification (HTTP Authentication)
HTTP Requests and Web Cookies
GET and POST HTTP Requests
An HTTP GET request is when you enter a URL in your web browser the URL send command of data request through HTTP where HTTP GET request to the webserver where the website is hosted(server), so the webserver in return sends the response for the browser to render it.
HTTP POST Request
The POST request method requests that a web server accepts the data enclosed in the body of the request message. The HTTP POST request contains the data you submitted through the web form.
Automatically Generated HTTP GET and POST Requests
Sometimes GET and POST requests are triggered automatically via certain HTML tags, or by a javascript. so there is no user requirement to take action or request data. Example; the <img> tag can automatically generate a GET request to the image link declared inside its src attribute.
Web and Session Cookies
Cookies are small files which are stored on a user’s computer. They are designed to hold a modest amount of data specific to a particular client and website and can be accessed either by the web server or the client computer.
A session can be defined as a server-side storage of information that is desired to persist throughout the user’s interaction with the web site or web application
Cross-Site Request Forgery How Work?
Mostly attack in CSRF is using the image tag (img src) in the HTML DOC coding. where an attacker can insert malicious link should send HTTP requests to the target, such as a GET request can be excellent. The benefits of using an image tag on the normal link tag (a href) are :
- Image tag does not require clicking the link compared Tag-A requires clicking on the link to activate the HTTP request.
- Nature of browsers is to send HTTP requests to visual objects such as picture or remote files (CSS, JS, etc.) even while loading the page without the user’s permissions. This means the user does not need to perform any action in order to see the image on the page, all he has to do is go to a certain site-specific browser sends HTTP requests to have to load the image. In this case, since the browser recognizes the HTML code of the image tag, it sends HTTP requests to load the image even if the SRC of the image is not really a picture, but a malicious link …
For those of you that use Fire-Bug(Firefox add-on) can see in the next snapshot example of sending an HTTP request from the browser to the server to load an image during the login of the user:
Also, CSRF attacks can be implemented not only through websites but through email messages. Since the mailboxes allow sending data to HTML format, the attached image perfectly legal. In this case, I can send a malicious email message to the huge amount of recipients, put a photo tag email body when the SRC contains a malicious link, when the slave opens the email, the desired action done.
Exploiting code examples:
HTMLUsing img tag:PHP Code:
<img style=”display:none;” src=”http://targetsite.com/change_password.php?new_password=123456″>
Using iframe tag:PHP Code:
<iframe src=”http://targetsite.com/change_password.php?new_password=123456″></iframe>
Java Scriptusing image object.PHP Code:
<script>var shahid new Image();test.poniz = “http://targetsite.com/change_password.php?new_password=123456”;</script>
These parameters are sent to the server using the POST method. so you can see the parameters in the URL Bar if the parameters are written though getting the GET method, EXAMPLE see. Code:
http://targetsite.com?users.php?db[webaddress]=http://www.hackersthirdeye.com&action=save
fine (simple the variable was in REQUEST method where it does not matter)
Suppose that Dork like this one:Quote:site:targetsite.com & intext:”Homepage” & intext:”email: “
Now, I’ve got all the emails of users and I can send them an email with the img tag, and when they will open it, their home page\website address field in their profile will change(To https://hackersthirdeye.com) done
Preventing Cross-Site Request ForgeryAttacks
An attacker can launch a CSRF attack when he knows which parameters and value combination are being used in a form. Therefore by adding an additional parameter with a value that is unknown to the attacker and can be validated by the server, you can prevent CSRF attacks. Below is a list of some of the methods you can use to block Cross-Site Request Forgery attacks:
Implement an Anti-CSRF Token
An anti-CSRF token is a type of CSRF protection.
What are actually tokens? This is a hidden random ID responsible for sending structured data, such as logging into forms, forms that allow registered users to update data or home page(in our case )
<input type=”hidden” name=”8pssf18ssdmf8s7p80fodi” value=’1′ id=”token” />
Since the tokens are defined, the attacker can not know what is the token of the slave, because every loading of the page the token will change to other random number\string.
