 Hello everyone, my name is Lakiya Garbhaal. We have seen dam vulnerable web app before. My friend Swapnel has shown you this app on Saturday. This is a great tool to test your skills of ethical hacking. We will check XSS attacks on this app. As told by sir before, there are two types of XSS. One is XSS, Reflected XSS, which is a non-persistent XSS and another is a stored XSS, which is a persistent XSS. So, let us begin with the two levels of security in DVWA as shown. A low level of security and a medium level of security. Also, there is a high level of security, where mostly none of the attacks work. So, we will try our attacks on a low level security and on the medium level security. So, first let us begin with the low level security. We start with XSS, Reflected XSS attacks. So, as you can see, this is a simple form, which asks what is your name. So, if I enter my name over here and then I press submit. So, it will simply show me my name as the response. What if I enter some other random characters in this same form field? So, we can see that this all the characters are are given to us in the response without any sanitization. So, this shows us that we can try this field for cross-site scripting attacks. So, let us insert another HTML tag for bold, simple bold tag in HTML. So, as you can see, the HTML tag has been executed and my name is now being showed in bold. So, we will try a script attack on this field. A very simple script to just say hello, a pop-up of hello. So, as you can see, when the script executed, when I submit the form, it gives me a pop-up hello. So, on a low level of security, we have successfully executed a simple attack, a simple cross-site scripting attack. Now, we will see the medium level of security. Let us try the bold tag again on the same field. Does it work in the medium security also? As you can see, the bold tag still works. So, let us try the script tag now. Now, you see that when I submit this form, the script tag no longer works. Now, let us try to find out what has changed from low level security to medium level security. Let us try another attack first. Then, we will see how it has changed. Notice how I have introduced another script tag within the existing script tag. We will see how this is helpful to us in attacking this form. Now, when I submit this form, the attack is successfully executed. To understand what is going on on the server side, we will take a look at the source code on both at the low level of security and the medium level of security. Let us take a look at the low level source code. So, as you can see, in the low level, there is no sanitization on the response. The web page simply, the server simply returns the name. Web page picks up the CTP response name and simply reproduces it on the web page. No sanitization over here. Let us check the source code at the medium level of security. Now, you can see that in medium level of security, the script is trying to replace script tags with null. How is this helpful to us is because we introduced an extract script tag within our existing script tag. So, when the browser stripped off the inner script tag, the outer script tags combined to form a complete script. So, this script tag inside, which I had intentionally put, is being removed by the server and then we get a complete script which can be executed. This facilitates the attack on the medium level of security. Now, we will see stored cross side scripting. Exceses stored. Exceses stored are persistent attacks wherein every time the web page is loaded, all previous attacks are still existing on the web page. So, let us take a look at the low level of security on excess stored attack. Remember that every time you do an excesses stored attack on DVWA, do not forget to reset your database from the setup menu because on the excesses stored web page, all the previous attacks that you have tried will be re-executed every time you reload the page. So, every time you go to the excesses stored page, before going there, go to the setup tab and reset your database. So, that the previous attacks are deleted and you get a fresh page to try your new attacks. So, let us take a look at the low level of security on excesses stored. Now, it is a simple form which asks you to enter your name and a message which will be displayed over here. A simple guest book. Let us try a script over here on the low level of attack. We will try a script to show the cookie from the browser, extract the cookie from this browser. Now, as you can see the low level of security does not sanitize the input. Hence, the attack is successful and we can see the cookie stored in this browser. Before we proceed, we should reset the database every time. Let us try the medium level of security. Notice how this time the attack did not work. We repeated the same attack that we did on low level of security and we tried the same attack on medium level of security. But as you can see, the attack did not work. What we input was simply returned to us after sanitization. The script tags have been stripped off. We tried to attack the message field. Now, we try to attack the name field. We try to write a script in the name field. First try with a simple bold HTML tag. But now, you can see that we are stuck. I cannot type any more characters in this field. This HTML field has been restricted to accept only 10 characters. I have already written 10 characters, so I cannot write any more characters. So, even a simple script, the script opening tag and the closing tags will extend to more than 10 characters. I cannot write a script in this tag. Here, we will make use of a tool that we have already studied before, the fire bug tool. Abhishek has shown a demo on that tool before. We will make use of fire bug over here. To edit the HTML on this page, to increase the size of this field, to write more characters and to be able to write a script in this field. Since we cannot write more than 10 characters in this field, we will open fire bug. Go to the HTML code for this form. As you can see, the max length of this form has been restricted to 10 characters. We can edit this using fire bug. We can make this as many characters as we want. We made it 100. Now, we can write a script in this name form also. Let us try with the basic script that we have already seen. A simple script to get the cookie from the browser. Now, even the name field has sanitization on the script tag. So, this attack also did not work. As we had seen previously in the medium level of security, that we are stripping out script tags from the script tags. So, let us try the second vector that we used, including a script tag within the script tag. Before we proceed, reset the database. Use fire bug to increase the length of this form field. When the internal script tag will be stripped off, the outer SCRI and PT will combine to make a script tag, which will be executed by the browser, thus facilitating our attack. So, as you can see, in this time, the attack is successful. So, the message field has been fully sanitized to prevent against all types of attacks, but the name field had not been fully sanitized to protect against all types of attacks. Only the name field was restricted to 10 characters, so that nobody is able to write scripts in that field. We used a known tool fire bug to extend the size of that field, so that we may write the script in that field and then attack this application. As we see in the source code, the message has been completely sanitized against all types of attacks. Strip all the slashes, mysql, real escape, the softmail has already explained. Remove all the HTML special characters, replace them with coded strings, but the name input has only been sanitized against replacing script with a null. So, we were able to attack it. So, these are the, to summarize, we saw two attacks on each type of security. On each level, we saw one attack on low level and medium level. For both accesses reflected and accesses stored, we saw two attacks, one that works on the low level and, but did not work on the medium level and one that works on both low level and medium level. So, in tomorrow's lab also, we will have questions on the similar lines plus a few optional advanced questions, which you may try if you want to learn a little more about that. See, as we saw that these script, these attacks were, these attacks were not very complicated or very tough, I mean very malicious attacks, but as I was already shown that they can be other attacks which are very malicious, which can transport your data to other web pages and, and steal important information from a browser. I will write down the sanitization functions that were being used by the application. The first one, as Swapnil must have already told you during a scale injection. The second one is to remove HTML special characters and replace them with coded strings. The third one was to replace a string and to replace the script tag from the string and replace it with null. So, these are the three functions, the special characters such as ampersand, angular bracket and quotation marks and other tag, another characters with special coded strings. So, that these are interpreted by HTML as, not as the HTML characters, but as simple characters that are being displayed as it is. Thank you.