Client Side Penetration Testing with Prasad Salvi

About this Episode:

Don’t let hackers execute different client-side attacks on your website. In this episode, Prasad Salvi will cover some of the most important concepts in his Pluralsight Web Application Penetration Testing: Client-side Testing course. Discover how to be proficient in performing client-side attacks like Cross-Site Scripting, HTML Injection, Client-side redirects, and how to fix them. Listen up!

TestGuild Security Testing Exclusive Sponsor

Micro Focus Fortify is the recognized market leader in application security and is the most comprehensive and scalable application security solution that works with your current development tools and processes. Try it today

About Prasad Salvi

Prasad is an Application Security Consultant, a certified ethical hacker and CISA certified professional with a primary focus on providing services across the Secure Development Life cycle, Application Security and Penetration Testing spectrum. He is a part-time bug bounty hunter. He is a blue team expert delivering security training courses to developers and testers to make them proficient in application security and develop secure products. He has worked with major financial institutions and vouched to create a culture of security.

Connect with Prasad Salvi

• Twitter: prasad_salvi
• LinkedIn:prasad-salvi

Full Transcript Prasad Salvi

Joe [00:02:36] Hey, Prasad. Welcome back to the Guild.

Prasad [00:02:39] Hey, Joe. Thanks so much.

Joe [00:02:40] Awesome to have you back. Before we get into it, you've done a few courses now for Pluralsight. For the folks that actually listened to episode 18, how is this course different from your previous course and testing of identity, authentication, and authorization mechanisms?

Prasad [00:02:55] So the first course that they had was more focused on the authentication and authorization part. At the course that I have just released talks about process scripting, HTML injection. So all the things that you can do on a browser on the client-side of an application and how it impacts the application is what we discuss in this particular course.

Joe [00:03:15] Nice. So I do know some of the prerequisites of the course. You mentioned that folks should know some JavaScript. How much programming knowledge you think a pen tester should have in general?

Prasad [00:03:25] I would say a pen tester should understand how the application behaves. The different context that the application shows the data that they're entering. JavaScript primarily helps you to understand the cross-scripting attacks. If there are some scripts that are blocked by the application, that's a preventive measure, but you should be able to tweak that particular script in a way that it executes and you'll get a cross-scripting pop-up on the screen. So in terms of the pen tester having programming knowledge, I would say it is always an added advantage to know the different programming languages if you don't know then I would suggest you to start learning Python and JavaScript, which helps you a lot as a pen-tester.

Joe [00:04:05] Great. So I think the course is broken into three major sections. You have exploiting cross-site scripting attacks, testing client-side redirects HTML injection and clickjacking, and the third one I think was on different types of storage, web local session topics. So I thought we dive into each one. The first one is for folks that don't know what is cross-site scripting attacks?

Prasad [00:04:31] A cross-scripting attack is something that you would receive a plain text script from the server. So you enter an untrusted data or a malicious script in the browser, let's say in the input field, and the server reflects it back in the response. So the browsers will think that a script has come back from the server. So I have to execute that to whatever is written in that script tag would be executed. So let's say if I want to know what Joe's current session ID I'll send you a script, I would say scriptalertdocument.cookie. And once when you click on it, I will get your current session ID on my box.

Joe [00:05:10] Nice. So how common is this type of attack? Is it the most common one usually?

Prasad [00:05:13] It's the most common and the famous one. So ideally, 60 percent of the applications in 2019 will bridge because of cross-scripting at that predominantly. So it is a very nice attack to execute. A lot of pen-tester about bounty hunters like this particular attack. But at the same time, my course also talks about how we can fix this attack of all the developer community so that my application is not vulnerable to such attacks.

Joe [00:05:38] Great. At the end of each of your –  the major session Java mitigation, before we dive into the mitigation, you talk a lot about XSS. So how has XSS evolved with the cross sight script attack normally?

Prasad [00:05:51] XSS is a short form of the cross-scripting attack. It has different types reflected, stored, and DOM Based, to which I have explained in the course. There's a given introduction so reflected would be I'm sending you a particular script and it gets executed. So I get a response back from you like a one to one communication in terms of a stored cross-scripting stored malicious script, let's say on a description box or a comment box in the blog site, whoever clicks on that particular link., who uses that blog site, I would get his or her session ID or cookie or any script that I have written. I would get the details of the users clicking on that. Usually, in terms of risk rating, tool cross-scripting would have a higher impact because the user base is pretty huge as compared to reflected which is just one to one. Your it's one to many. The third time is DOM Based XSS so DOM is basically the document object model just in the browser. So how DOM differs from reflected and stored is in that there's no communication with the server. So when I said at the beginning that cross-scripting, you receive a malicious script from the server and the browser just executes that. In the case of DOM Based XSS it's pure client-side, a code that is executing the script so the server doesn't instruct anything. The request doesn't even reach the server because your client-side the code that you write, like let's save into that location (as???) or if you're using an EVAL function, which is one rebel. So the client-side of the browser will execute it so it doesn't have to wait for the server to tell it to execute something. It will execute on its own. So that's the difference between node reflected and DOM.

Joe [00:07:25] Got you. So how does this normally occur?  Does the attack get a hold of your server and then modifies your files on your webserver? Someone goes through it then that while the attack is started.

Prasad [00:07:35] So if we talk about reflected, as I said, it's one to one, so I might send you an e-mail or a phishing link or any website that unsecure that you visit. You might see a lot of pop-ups coming up saying that free software or free upgrade or free movie tickets and stuff like that. So the action that you said behind that particular pop up is that send me the current users session ID. So for you, you're clicking or you're closing a pop up with CS free software, but in the background, action is said that send me your session ID. In case of stored, I will store it on a comment box or a description box so that stored on your web server. So anyone visiting that would click on it. This is what I've shown in the demo as well of the course. If I'm on a  blog site if directly I post a link or people want to click on it random links. But if I say that even I codel or I blog on the same topic, you know, this is my blog link. Why don't you check it out and give me feedback? So a lot of people might click on it to view my blog. So the blog might or may or may not open, but I would definitely get the current users session ID. And if that happens to be the admin user, I can utilize that session ID to log in as an admin and do a lot of damage inside the application.

Joe [00:08:44] So and I've been hearing a lot of news about ransomware. Is this type of cross sites scripting attack?

Prasad [00:08:48] No, that's completely a different one. This cross-scripting is basically an attack for the web applications.

Joe [00:08:56] Got you.

Prasad [00:08:56] Whereas ransomware can affect your operating system and encrypt everything. But we can utilize the cross-scripting attack. The impact that we have of cross-scripting is I can deface a particular website. I can redirect you somewhere. So if I redirect you to a website that installs a malware on your system or runs a similar system, then I can definitely say that I can utilize cross-scripting as a tool for the ransomware to get installed on your system.

Joe [00:09:24] Yeah. Makes sense. So what tools do you usually use to test this type of attack? Are you just using Burp suite throughout this course?

Prasad [00:09:30] Yes, so Burp suite is like one of the great tools that we have for pen-testing. We also have a lot of GitHub links where a lot of researchers have posted different types of scripts that become across. So a lot of bug bounty hunters, researchers find new scripts to circumvent the different types of mitigations in place. Let's say we have an application firewall or any other techniques that have been implemented by the developer community. So once that is successful, they post it on pages and, you know, you get a good amount of payloads, which you can try on all the applications that you're testing.

Joe [00:10:02] So what are some ways folks can mitigate this type of attack?

Prasad [00:10:06] So the first and foremost thing I would say is input validation and output encoding. So, for example, if I have an input field that accepts only phone numbers, for example, and if I enter my name. So usually you see a red line coming on the browser below that text box, it says please enter a valid value or valid number. Now, that is input validation that I'm checking my input, what the users are entering. But if I utilize a Burp suite proxy, I can actually bypass that validation so I can capture that request in the proxy. And I can again, change the phone number to my name, for example. So when this request reaches the server, the server should also have a mechanism to check, validate, and encode that thing. If it doesn't, then it would send everything back in cleartext. So that's how the script gets executed. But if I have actual encodings in place on the server-side, so even if I send a script that would be coming back as an encoded value. So for example, the less than and greater than symbol script tags would come back as ampersand LT and ampersand GT, which is the HTML entity encoding for less than and greater than. So ampersand LT is less than ampersand GT is greater than. So once the browser sees these values coming back from the server, it treats them as a string or as a text because they don't have the script text. They are just normal text so it doesn't get executed. So you are safe. So even if someone tries to bypass your clients and validations, you have solo side controls in place. So those are the first two and the best recommendations and validation and output encoding. The third one is having a white list in place. So it's completely different from a blacklist. A blacklist is a very bad recommendation for any security professional or a developer. So why recommend a blacklist is because I, as a developer or as an application owner, would know what other different special characters are acceptable in my application. Let's say I have odd rate of all email addresses from a user name so I can allow that. So if I have a white list created of all the special characters which are allowed. So in order to execute cross-scripting, you either need the script tags or you need some on click on load sort of event handlers. But there needs to be some sort of special character associated with that. Let's say a single cord or hyphen or a normal bracket. So if I know what other things are allowed in my application, I can just create a white list and whenever an input comes to the server, the server just checks the white list. Are these things allowed in the request? If yes, process it. If no, you can just delete those. But if we have a blacklist, you might have to add a lot of scripts on a daily basis. Because as I said data goes to all the researchers come up with different scripts on a daily basis. So instead of having a blacklist, which has thousands of scripts and every time input reaches the server, the server has to compare that input against a thousand entries that you have and then come to a conclusion whether you could process it or not. So it's always good to go for the white list. Then for output encoding, OWASP  has a very good library called the OWASP Java encoder project. So you don't have to write a custom code for encoding because sometimes you can go miserably wrong when you try to customize the encoding. Change of that you can use or you can import the OWASP Java encoder library in your code and it will help you to encode all the special characters that are coming to a server. Similar to that, we have a library in .net as well. We call as the AntiXSS Library. So it does the same thing of encoding. So you're safe from the server-side as well.

Joe [00:13:44] So I really love this course. So you talk about each attack and you give an actual demo and then you give a mitigation. So folks definitely you need to check it out to actually get a full understanding of it. What I also like about the course is a  lot of times people maybe have a hard time when they're practicing and finding a way to kind of create these attacks and so they can learn how to stop them. And to keep the free website you used bWAPP? What's that site you used in the course? It was pretty cool.

Prasad [00:14:09] Yeah, it's a bWAPP with the free form is buggy web application. So it's a great intentionally one level application. So if anyone wants to practice security testing or penetration testing, there are certain intentionally one-level applications available. So bWAPP is one of them. So feel free to download it on a VM or on a Kali Linux and test it. It has all types of vulnerabilities that are possible. So it basically has a list of OWASP top 10 vulnerabilities. So all possible places where you could find vulnerability, let say it gets a request or a post request or an Href tag. So you have all those things placed in there. You just have to select a vulnerability that you want to try. And it gives you that page, which is vulnerable to that particular issue, and you keep on trying and try to explore that particular thing. So it's really great app. Everyone should definitely download and start using it.

Joe [00:15:01] Great. So the second kind of where you dive into another type of attack is testing client-side redirects HTML injection and clickjacking. Is there like a bigger name for this type of attack, like the man in the middle? How would you classify these types of attacks?

Prasad [00:15:14] Ideally, to perform most of the attacks, the attacker might need to perform a man in the middle attack. But when we talk about client-side redirects, it's basically redirecting the users from the legitimate website to a malicious website. Now, let's say I want to run a phishing campaign so I can check for the different websites on the Internet, which is something as, let's say, redirect to perimeter in the URL or in the request body. And I'll try to change them to my website. So whenever you click on a particular button instead of, let's say for logout, for instance, if I click on logout, I should be redirected to the login page but when I log out, I am redirected to a different domain or a different URL altogether. And it might ask me to enter my credentials again or give some personal details. And I, as the end-user, as a victim, would think that it is the same site or a subset of the site that I was previously on and asking me for some details or some survey to be filled out and I can easily give out my personal details. Client-side redirects are usually used for the phishing campaigns. HTML injection, again, it has some similarities with XSS because it uses HTML tags, the script tags again. Let's say the script might be blocked. The mitigation that we spoke about, the developers might have implemented that. So what I can do is I can create an HTML page within the comment or the description box. So let's say I want to enter a comment. Instead of entering a normal comment, I write an HTML code that creates a login page, or let's say username and password text boxes. And I submit that particular comment. And if the server is accepting HTML tags, it will reply back the same to the browser and the browser will actually show a user name and password box in the comment order description section. So again, the unsuspecting user might feel that okay I have to enter my username and password in there before I enter any comment so that he or she might enter his username and password. And again, the action that has been set on the login button is that send me his or her user credentials on my machine. So that's a very dangerous attack as well. Talking about clickjacking. It's basically an attack where you monitor the different clicks that the user is making. So you might be on a genuine application, but the application might be hosted within an iframe or an opaque frame, which you cannot see. You are just accessing your application on a daily basis. But the clicks that you're making or the data that we are entering and let's say clicking on submit it or login, that might be sent to an attacker, to his or her machine. So it is very important to have the mitigations for clickjacking implemented as well.

Joe [00:17:52] So how concerned should folks be about these types of attacks? And I guess all of them they should be concerned about. Are some more difficult to implement than others? Or is it just, you never know?

Prasad [00:18:00] Performing the clickjacking attack I would say is pretty simple. I've also given the code in my demo and it's just a one-line code. So you have if you're comfortable with HTML coding, you can just create a normal HTML base on one line of code. So you write an iframe source as let's say the URL that you wanna test and then you give a height and weight for it. Let's say eight hundred, eight hundred, which is less than the standard size of a browser. So when you try to open that, you have to save it on your machine. And when you try to run that HTML file in a browser, you'll see a small frame open in your browser at the corner of the height and weight parameters that you've given. And if your application loads inside that iframe, it means that your application is vulnerable to clickjacking attack because the URL would be the place where you have stored, let's say, cdesktopclickjack.puc.html. So ideally you have opened an HTML page from your local machine, but the actual website got open in there, which means it is vulnerable to clickjacking.

Joe [00:19:02] So what are some mitigation strategies for these types of attacks?

Prasad [00:19:05] The mitigation of clickjacking is to use the extreme option so there is a security header. So ideally I would know that what are the different websites which are allowed to load content on my website or create an iframe on my website so I can give the server instruction that only these sites will create again, similar to whitelist. So in extreme options, we give the sites that are allowed to load content. There's something called as content security policy. So extreme option is probably phasing out soon. So there's something called as content security policy where you defined everything that is allowed inside of the application. So if I'm loading certain scripts from X URL, I write the URL in there as a script source. If I'm loading some images, I write them as image source. So I believe anywhere the browser is checking that. Shall I open this particular application in iframe? Or is this URL let's say Cdesktop something, is it part of the content security policy? If it is not, then it will just give you a blank frame which says that this application cannot be opened in an iframe.

Joe [00:20:11] Alright cool. So the next one you went into is testing different types of storage. And for some reason, I never thought of storage when I came to security. So what do people need to be concerned about then when testing for security issues, specifically with storage?

Prasad [00:20:24] Yes. So this one is particularly for the HTML5, so HTML5 introduced a local and session storage. So why it is important from a security perspective is because local storage is something that is never deleted or never expired. So once there is something which is stored in the local storage, it stays there forever. So if you're storing some secrets or usernames and passwords in your local storage, then there's a possibility that anyone can just go to the developer tools, open up the local storage and check for the values. And even if you log out they're still out there. The session storage, on the other hand, is something that is expired after you log out of or you close the browser. So for a pen-tester, it is very important to check the local storage because that's where you find all the critical things or the sensitive things if at all, they are being stored by the developers. So it doesn't require any tools as such. But you can also utilize the developer tools of any browser. I just go through the applications, like if I'm using Mozilla or Chrome, open the developer tools using function F12 and then go to the applications window. In that, you have the local and session storage and you can just click on local storage and you'll see all the URLs that utilize the local storage. And if you click on any of those you'll see what are they actually storing. Like in bWAPP, you have the secrets, all the username, and password stored in the local storage. So local and session storage are basically required from a performance standpoint wherein the client doesn't have to reach out to the server every time. If I store my session ID in the session storage and if I've opened 10 tabs of the same application and trying to book a movie ticket or a flight ticket, the same session ID would be utilized across all the 10 tabs. But if I'm not utilizing session storage, then there's a possibility that I might have a new session ID and I might end up booking two tickets or two different types in the same puzzle. So that's why I HTML5 give this feature called a session storage. But that's safe because that was deleted once you close the browser or log out as compared to the local store. So if you want to store something store it in the session storage because that has an expiry. Don't store it in the local storage because it stays there forever.

Joe [00:22:36] So is this a newer type of attack that you're seeing an uptick in or just something people need to be aware of when they're using HTML5 in general?

Prasad [00:22:43] It's definitely not a newer attack. It has been predominately there since HTML5 was introduced. But people should definitely be aware especially the pen testers or the people listening to this podcast if you're performing security tests. I've usually focused on cross-scripting, SQL injection. So these are some low hanging fruits that you can check for. And these attacks with local storage can also be of high risk if they're storing username and password in clear text to the local storage.

Joe [00:23:07] NIce. So this might be an odd question. I know when you create a course, sometimes you have a time limit based on whatever you submitted to Pluralsight as your table of contents, with you on the cover. So is there anything you left off or that you think other types of attacks folks should know about that is similar to what you listed here that you weren't able to go into detail in the course itself?

Prasad [00:23:25] No, so these ones are the ones that are recommended by the OWASP testing guide. So all these attacks are taken from there. So if you're testing or pen testing the client side, these are the attacks that you should check for or the vulnerabilities that you should check. The application prevents them or it is vulnerable.

Joe [00:23:42] So when you're doing a pen test, is there like a percentage of tests where you focus on the client-side and a percentage you focus on authentication? Does it just all depend on what type of application, what's involved in that particular protection for that application?

Prasad [00:23:56] Yeah. So it all depends upon what we have as the scope. But let's say if you say that the entire application from the login to logout is in scope of the pen test, so I will start from the login page. I'll check if I can bypass the authentication mechanism if I can reset the password, what are the different techniques, how can I reset it. And after login, I can check if the session management, if I'm getting a different session ID as compared to the one that I had on the login page. Or once I authenticate the application on HTTPS or can I also access an HTTP. This means that the data can be sent for clear text. What are the different tabs in the application? Are there any different rules if the admin user can access 10 tabs and a normal user can access only five? Can I change the URL and see if I can access the admin's page as well? Can I check someone else's data, someone else's transaction by changing something into URL or the ID in the URL or in the request body and of course after I logged out, I can also check if the session ID is getting nullified so that it's invalidated and so the application is safe from something called the session replay attack. So there are different types of test cases as you usually go through the OWASP testing guide. It has it on hundred plus test cases, which talks about authentication, authorization, client-side testing, file uploads, security headers more specific to the technology let's say if you're having a HTML5, you can test these things like local storage, session storage. So if you're using Silverlight, there might be a different set of test cases. So it all depends upon the technology stack. But some test cases like the client-side ones and authentication would be applicable to all the applications out there.

Joe: [00:25:35] Okay, Prasad before we go, is there one piece of actionable advice you can give to someone to help them with the security testing pen testing efforts? And what's the best way to find and contact you? Or learn more about your course Web Application, Penetration Testing, Client-side Testing?

Prasad [00:25:51] So they can connect me on LinkedIn. My ID is Prasad-Salvi. I'm an application security consultant and talking about pen testing and if you wanna learn about it, I would suggest going through the OWASP website testing guide, download bWAPP, or DVWA which is a damn vulnerable web application or a lot of vulnerable applications out there, intentionally vulnerable. Don't try to attack any random application on the Internet. You might be in trouble because it's being monitored. It's not allowed. You can always go to test in a controlled environment, let's say in the VM on intentionally vulnerable applications and hands-on is the only technique where you learn. So try to participate in the different capture the flag events. Try to learn how different attackers or different researchers do it. Follow them on let's say Twitter or read their blogs and you're good to go.

Rate and Review TestGuild Security Podcast

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page. Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.