Browser Only Web Application Testing

By: Ian Briley, Security Consultant

Spoiler Alert: Burp is the number one tool most people use while testing web applications. If you want to be an open-source champion, ZAP from OWASP is a good choice as well. I’m going to share some features of using just a browser for testing web applications.

Be The User

I’m going to be honest; I have no idea why this next idea works but it has never let me down. I find it really useful to just close Burp and interact with the web application as a user with a browser. This helps me get into the mind of what a developer expects a user to see and do on the application. Typically, I’ll keep a page open in my notebook and jot down any notable functionality, input fields, or parameters that caught my eye to look at later.

 

 

Let’s take this a step further.  After running through the application as a user with a browser, I will then start to use the developer tools to get into the headspace of what developers did to create the user experience.

Browser built-in tools

A majority of the stock browsers have some nice tools and features for reviewing web applications. You can instantly access these tools by clicking CTRL+Shift+C. Granted, a big chunk of these tools are not truly useful for security testing. Tools like the “Accessibility” tab have no use in what we are trying to do.

 

There are a handful of very useful tools though. The tabs I find the most useful are Inspector, Console, Sources/Debugger, Network, and Storage.

Inspector

Inspector is a step up from just right clicking and viewing the source of the page. This will show all the DOM goodies buried into the page as it’s presented to the user. To this day, I still get lucky with developer comments, finding functionality protected by client-side controls, and getting a feel for how the developers name their routes and files. It is these things that make it still worth it in this day and age to pop on the inspector tool to take a peak “under the hood”. One Journalist even found SSN of teachers embedded into the source code.

Console

Console is a way to interact with the webpage’s JavaScript functions. This tool can also make it possible to manipulate how the site renders. Back in the day, Hack the Box had the best example of this as a challenge to generate an invite code enabling you to join. Inside one of the JavaScript libraries you could call on the function makeInviteCode(). Typing this into the console would then to spit out a string that you can decode to get further into the challenge. You can see how people successfully got an account on Hack the Box here.

 

 

Another good use of the Console is that it can be reviewed for errors on a page. This helps us understand what technologies the application is trying to load or reach out too and what actions we did to error it out. Every now and then,  you can control settings here as well!

 

 

The thing I tend to use console the most for is to change websites with “dark mode only” GUI to a light mode so I can get better screenshots. This can be tedious though, because each website requires your own copy and paste code snippet to undo the “dark mode only” styles.

Source/Debugger

Source/Debugger is the other hand of reviewing JavaScript code and how it interacts with a library. Different browsers will refer to this tool by either Source or Debugger. TryHackMe has a great tutorial for this. If you’ve ever had to debug code in an IDE before, it’s the same exact process. You set a breakpoint and reload the page. This will allow you to step through a function on the webpage. In the event you see a weird behavior, you can now set one or several breakpoints at the function to review the logic of the JavaScript code in question.

 

 

Network

Network tool simply shows us what the page requested when loading. This can reveal to us the order of how certain assets are loaded, what initialized the call, where they are reaching out, how long the request took overall, and where they fall on the timeline. For example, let’s say I’m not sure what’s handling the login logic for the web application. I can use the network tab, and review the waterfall chart as shown below. Generally anything web related that needs processing will take longer to get a server response.

 

 

 

Additionally, you can view the headers for the requests and responses under the Network tab. While looking through this, you can find interesting information like even custom headers that can be abused. I find less abusable information contained in the headers, but this is a very common place for CTFs to hide information you need.

 

 

Storage

Storage is where we can find all of our Browser Objects and web browser cookies. I am willing to bet that you would be surprised at what data you can find and manipulate in this tab. Developers have a tendency to only base64 encode data here thinking that’ll be enough. As an example, a popular word guessing game had actually stored the answer to the mystery word right in the browser object boardState. This has now been removed, but it is interesting to see what developers will push off into the browser to avoid having data sent between the browser and server repeatedly. I have found JWTs (JSON Web Tokens) containing very sensitive data stored here. I have used values from here to guess other account IDs, and obviously saving time on daily word challenge games.

 

Conclusion

You can do plenty of web application hacking with only using a browser, and that’s not even getting into the realm of web browser extensions such as Cookie Editor, Note Taker, Wappalyzer, and the tried-and-true FoxyProxy. Check out my SiegeCast “Web App Testing: Simplified” and keep an eye out for my next article. I will cover what extensions I think are worth your time for your web browser hacking needs.

 

About Ian Briley, Security Consultant

Ian Briley has over 10 years of experience in information security consisting of The United States Armed Forces, the Healthcare industry, Security Operation Centers, and Security Consulting. Ian is an experienced presenter, trainer, developer, maker, and researcher. Ian enjoys attending local security focused groups and learning more about cloud-based environments and solutions

Certifications:
GWAPT, eJPT, CySA+, SSCP, SEC+