Browser Only Web Application Testing
By Red Siege | July 24, 2023
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.
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.
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 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.
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.
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 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.
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.
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
GWAPT, eJPT, CySA+, SSCP, SEC+
Related StoriesView More
By Red Siege | September 22, 2023
from Jason Downey, Security Consultant In our digital world today, where cyber stuff keeps changing all the time, there’s this sneaky attack method that’s been popping up more and more […]Learn More
By Red Siege | August 22, 2023
by Jason Downey, Security Consultant The Basics Password cracking is a key tool in every penetration tester’s toolbox and is something blue teamers should do on a regular basis […]Learn More
By Red Siege | July 31, 2023
by Mike Saunders, Principal Security Consultant In a recent blog , we discussed how encrypting shellcode leads to increased entropy, which may result in your shellcode loader being blocked and/or […]Learn More