Sensitive Data Exposure and HTML Injection

Sensitive Data Exposure & HTML Injection

Today I’ll be trotting along the adventurous Bug Hunting path. I’m forcing myself to empty all previous knowledge that I possess about bug hunting. Forcing myself to approach the craft with a fresh and open mind. Literally, all the way back to the beginning we go.  

It’s repeatedly drummed into our heads to make a habit of viewing the source of web pages in search of valuable information left around in the comments. As minute as it may seem to stumble upon such low-hanging fruit, upon reflection of my time spent as a developer, I can see how this could play out.

For instance, taking over a previous developer’s role, there were quite a few times where information left in comments served as key pieces of info that I needed to rebuild an application. As I took over and grew in the role, over time I began to rely on my own comments to map my way through figuring out how a piece of code was intended to work. Chances are, if those applications are still being used today, the developer who came behind me had those same “clues” at their disposal. I never went back and scraped my comments from the code before I left.

So, now when I come across pages such as this-

I tend to want to view source.

In fact, as a training exercise, for about a month, I’ll randomly pick a web site to visit and view source. For one, to make it a habit. For two, to see if there’s any low hanging fruit laying around in the wild. Just never know what can be found and what those findings could lead to.

Now…

Before moving into HTMl Injection vulnerabilities and how they can also be leveraged to perform XSS attacks, I want to take a brief step back before proceeding. It was easier for me to grasp “injections” by conceptualizing view-source compared to that same code open in a text editor, where one is able to “inject or insert” code directly into the page, serve it up to a browser and it be displayed as a web page. One can’t insert code directly into the view-source, refresh the web browser and the “injected” code be persistent on the web page.

For example, I’m not able to inject or insert code into the highlighted white space in the following screen shot, and have that code be persistent.

That being the case, then I should by no means be able to visit a web page from my computer, “inject” code into an entry point of the web page and have that code be persistent when the page refreshes. Like shown in the following screen shots.

However….

Since I was very well capable of doing that, we soon find that we may be capable of doing much, much, more like say, DOM Based XSS to steal user’s cookie values?

But that’s for another day. Hack on Ladz and Gentz!