Client Side Penetration Testing with Prasad Salvi

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey it's Joe and welcome to another episode of the Test Guild Security Podcast. Today we'll be talking with Prasad Salvi all about his new pluralsight course on web application penetration testing, client side testing, which is a really cool topic. So loyal listeners of the show will remember him from episode 18 which was really a highly rated episode. I got a lot of great feedback on it, so really great to have Prasad back. A application security consultant, a Certified Ethical Hacker and a CISA Certified Professional with a primary focus on providing services across the security development, lifecycle, application security and penetration testing spectrum. He's also a part time bug bounty hunter and 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's also worked with major financial institutions and really has created a culture of security everywhere he goes. Really excited to have him back on the show. You don't want to miss this episode. Check it out. Before we get into this episode, if you haven't already, I highly recommend you head on over to secureguild.com and grab your security testing ticket now. It's an online conference dedicated 100% to helping you succeed with all your security testing efforts. It's a great, great event for beginner security testers, folks that may not be hardcore security hackers but want to add more testing techniques to the toolkit. This is the online event for you. Head over to secureguild.com and register today. It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits and against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com app security hey Prasad, welcome back to the Guild.

Hey Joe, thank you so much.

Awesome to have you back. Before we get into it, you've done a few courses now for Pluralsight. For the folks that actually listen to episode 18, how is this course different from your previous course on testing of Identity authentication and authorization mechanisms.

So the first course that I had was more focused on the authentication and authorization part. 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.

Nice. So I did notice in 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, I would say a pen tester should understand how the application behaves, the different context that the application shows, the data that you're entering. JavaScript primarily helps you to understand the cross scripting attacks. If there are some scripts which 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 get across the scripting pop up on the screen. So in terms of the pen tester having a 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.

Great. So I think the course is broken out to three major sections. You have exploiting cross site scripting attacks, testing client side redirects, HTML injection and click jacking. And the third one I think was on different types of storage web local session topics. So I thought we'd dive into each one. First one is for the folks that don't know what is cross site scripting attacks.

Cross site scripting attack is something where you 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 would think that a script has come back from the server, so I have to execute that. So whatever is written in that script tag would be executed. So let's say if I want to know what's Joe's current session id, I'll send you a script which says script alert, document cookie and once you click on it, I will get your current session ID on my box.

Nice. So how common is this type of attack? Is it the most common one?

Usually it's the most common and the famous one. So ideally 60% of the applications in 2019 were breached because of process scripting attack predominantly. So it is a very nice attack to execute a Lot of pen testers and bug bounty hunters like this particular attack. But at the same time my course also talks about how we can fix this attack for the developer community so that my application is not vulnerable to such attacks.

Great. At the end of each of your the major sessions you have mitigation. Before we dive into the mitigation, you talk a lot about xss. So how has XSS evolved with the cross site script attack?

Normally XSS is short form of the cross site scripting attack. It has different types reflected, stored and DOM based which I have explained in the course to give an introduction. So reflected would be I 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 stored across the scripting store. A malicious script, let's say on a description box or a comment box in a block site. Whoever clicks on that particular link who visits 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 store, cross scripting would have a higher impact because the user base is pretty huge as compared to reflected which is just one to one year, it's one to many. The third time is DOM based accesses. So DOM is basically the document object model which is in the browsers. 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 crosses scripting, you receive a malicious script from the server and the browser just executes that. In case of DOM based access, it's pure client side 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 say window location, hash or if you're using any eval function which is vulnerable, so the client side or 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 stored, reflected and dom.

Gotcha. So how does this normally occur? Does a attacker get a hold of your server and then modifies your files on your web server? Someone goes to it, then that how the attack is started.

So if you talk about reflected, as I said, it's one to one. So I might send you an email 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 a free upgrade or free movie tickets and stuff like that. So the action that is 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 which says 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's 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, people won't really click on it. Random links. But if I say that even I code or I blog on the same topic, you know, this is my blog link, why don't you check it out and give me a feedback. So a lot of people might click on it to review 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.

So, you know, I've been hearing a lot of news about ransomware. Is this type of cross site scripting attack?

No, that's completely different one. Okay, this cross site scripting is basically an attack for the web applications, whereas ransomware can affect your operating system and encrypt everything. But we can utilize the cross scripting attack. The impacts that we have of process scripting is I can deface a particular website, I can redirect you somewhere. So if I redirect you to a website which installs a malware on your system or ransomware system, then I can definitely say that I can utilize cross scripting as a tool for the ransomware to get installed on your system.

Well, yeah, it makes sense. So what tools do you usually use to test this type of attack? Are you just using Burp Suite throughout this course?

Yeah. 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 they come across. So a lot of bug bounty hunters, researchers find new scripts to circumvent the different types of mitigations in place, let's say with 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.

Cool. So what are some ways folks can mitigate this type of attack?

So the first and foremost thing I would say is input validation and output encoding. So for example, if I have an input field which accepts only phone numbers, for example, and if I enter my name, so usually we see a red line coming on the browser below that text box which says please enter a valid value or valid number. Now that is input validation, where 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 and encode that thing. If it doesn't, then it will send everything back in clear text. 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, the script tags would come back as Ampersand LT and Amphorson gt, which is the HTML entity encoding for less than and greater than. So Ampersand LT is less than, Amperson 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 tags, they are just normal text so it doesn't get executed. So you are safe. So even if someone tries to bypass your client side validations, you have server side controls in place. So those are the first two and the best recommendations in validation and output encoding. The third one is having a whitelist in place. So it's completely different from Blacklist. A blacklist is a very bad recommendation for any security professional or a developer. So why we recommend a blacklist is because I, as a developer or as an application owner, would know what are the different special characters which are acceptable in my application. Let's say I have at the rate for email addresses for my username, 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 process 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 quote or hyphen or normal brackets. So if I know what are the things which are allowed in my application, I can just create a whitelist 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 that I could. Researchers come up with different scripts on a daily basis. So instead of having a blacklist which has thousands of scripts, and every time an input reaches the server, the server has to compare that input against the thousand entries that you have and then come to a conclusion whether it should process it or not. So it's always good to go for a whitelist then for output encoding, OWASP has a very good library called as 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. So instead 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 called as the Anti XSS library. It does the same thing of encoding. So you're safe from the server side as well.

I see. I really love this course. You talk about each attack and you give an actual demo and then you give a mitigation. So folks definitely 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 finding a way to kind of create these attacks and so they can learn how to stop them. And I think you have the free website you use. Bwap, what was that site you used in the course? It was pretty cool.

Yeah, it's a BW app with full form is buggy web application. So it's a great intentionally vulnerable application. So if anyone wants to practice security testing or penetration testing, there are certain internationally vulnerable applications available. So BW app is one of them. So feel free to download it on VM or on a KALI Linux and test it. It has all TYP vulnerabilities that are possible. So it basically has a list of OAS top 10 vulnerabilities. So all possible places where you could find it. Vulnerability, let's say In a get 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 exploit that particular thing. So it's a really great app. Everyone should definitely download and start using it.

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 is a man in the middle? Or how would you classify these type of attacks?

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 is 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 has something as, let's say redirect to parameter 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'm 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 an 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 there. Client side redirects are usually used for the phishing campaigns. HTML injection, again, it has some similarities with XSS because it uses the 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 which creates a login page or let's say username and password text boxes and, 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 username and password box in the comment or the 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 click jacking, 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're entering, and let's say clicking on submit 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.

So how concerned should folks be about these type of attacks? And I guess all of them, they should be concerned about some more difficult to implement than others, or is it just. You never know.

Performing the clickjacking attack I would say is pretty simple. I've also given the code in my demo. It's just a one line code. So you have, if you're comfortable with HTML coding, you can just create a normal HTML page of one line of code. So you write an iframe source as, let's say the URL that you want to test and then you give a height and width for it, let's say 800, 800, 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 once you try to run that HTML file in a browser, you see a small frame open in your browser at the corner of the height and with parameters that you have 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 C desktop clickjack poc HTML. So ideally you have opened HTML page from your local machine, but the actual website got opened in there, which means that is vulnerable to clickjacking.

So what are some mitigation and strategies for these type of attacks?

The mitigation for clickjacking is to use the X frame options. There's a security header. So ideally I would know that what are the different websites which are allowed to load content in my website or create an iframe in my website so I can give the server instruction that only these sites so create. Again, similar to whitelist. So in Extreme Options we give the sites that are allowed to load content. There's something called as a content security policy, so Extreme Options is probably phasing out soon. So there's something called as a content security policy where you defined everything that is allowed inside an 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 ideally, whenever the browser is checking that, shall I open this particular application in iframe, or is this URL, let's say desktop 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.

Very cool. So the next one you went into is testing different types of storage and for some reason I never thought of storage when it came to security. So what do people need to be concerned about then when testing for security issues?

Specifically with storage, this one is particularly for the HTML5. So HTML5 introduced the local and session storage. Why it is important from a security perspective is because local storage is something which is never deleted or never expired. So once there's something which is stored in the local storage, it stays there forever. If you're storing some secrets or usernames and password 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 still are there. The session storage, on the other hand, is something that is expired after you log out 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. Just go to the applications. Like if you're 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 see all the URLs that utilize the local storage. And if you click on any of those, you see what are they actually storing. Like in BWA app you have the secrets or 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 is a possibility that I might have a new session ID and I might end up booking two tickets or two different tabs in the same browser. So that's why HTML5 gave this feature called a session storage. But that's safe because that is deleted once you close the browser or log out as compared to the local storage. 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.

Yes. So is this a newer type of attack then you're seeing an uptick in or just something people need to be aware of when they're using HTML5 in.

General, it's definitely not newer attack. It has been predominantly there since HTML5 was introduced. But people should definitely be aware, especially the pen testers or the people listening to this podcast. If you are performing security test, we usually focus 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 in the local storage.

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. What are you going to cover? So is anything you left off or that you think other type of attacks folks should know about that are similar to what you listed here that you weren't able to go into detail in the cost itself? No.

So these ones are the ones that are recommended by 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.

So when you do an append test, is there like a percentage of tests where you focus on the client side and percentage you focus on authentication or just all depend on what type of application or what's involved in that particular architecture for that application?

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 I can 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 over clear text. What are the different tabs in the application? Are there any different roles? If the admin user can access 10 tabs and a normal user can access only 5, can I change the URL and see if I can access the admins page as well? Can I check someone else's data, someone else's transaction by changing something in the URL or the ID in the URL or in the request body? And of course after a logout I can also check if the session ID is getting nullified so that is invalidated so the application is safe from something called as a session replay attack. So there are different types of test cases as usually go through the OWASP testing guide. It has around 100 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 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.

Okay Prasad, before we go, is there one piece of actual advice you can give to someone to help them with their security testing, pen testing efforts and what's the best way to find contact you or learn more about your course? Web application penetration testing Client side testing.

Yeah, 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 want to learn about it, I will suggest go through the OWASP website testing guide, download BW App 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 been monitored, it's not allowed so it's always good to test in a control environment, let's say in a 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.

Thank you Prasad for your security testing awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com S33. And while you're there, make sure to click on the Try Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. And if you haven't already, as I mentioned at the beginning of the show, head over to secureguild.com and secure your security ticket for the 2020 online event. Dedicated 100% to helping you succeed with creating awesome security testing. It is an awesome event for beginners. You don't want to miss it. Head on over to secureguild.com so that's it for this episode of the Test Guild Security Podcast. I'm Joe. My mission is to help you succeed creating end to end full stack security testing awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.