WTANZ04: Jarlsberg

Last Sunday afternoon, for the WTANZ session, we were asked to go through http://jarlsberg.appspot.com/part1 at our own pace and then trade notes afterwards. The site, through Jarlsberg (/yärlz’·bərg/) which is this cheesy app with known vulnerabilities, aims to show how to attack an app using common web vulnerabilities. On hindsight, part1 was only upto familiarizing yourself with Jarlsberg but most of us (i think) went on to the XSS topics. I think one or two even made it up to the next part on elevation of privilege.

Back where I used to work, some workmates and I used to tinker and find some bugs in the internal apps. We used to find the html we entered in some input field was rendered rather than escaped. And occasionally, there were alert messages and ruined layouts that were triggered. Previously, I thought they all fell under XSS. Through the Jarlsberg codelab, I found out some distinctions.

For instance, reflected XSS is when the hack is in the actual request e.g., when you create a link that points to some URL with a malicious script (although not really malicious) like this. A stored XSS is when you store the hack where it would be retrieved when the page gets requested e.g., when you post something like alert(1) in some input field, and the alert gets displayed when that post is retrieved. There’s also file upload XSS for apps that allow the upload and retrieval of file attachments. The uploaded file could contain some scripts that aren’t expected to be executed.

As for elevation of privilege, I guess I had stumbled on to something that could be categorized as that in an internal system that we used in a previous company. It was a forum and I was able to access a certain functionality that wasn’t supposed to be available to me. They may have hidden the button to access it, but that was all they did to keep me off of it. It was still possible to access the functionality by modifying the URLs and there were no validations when I submitted the request.

Anyway, this weekend’s session tells me something I’m well aware of and that is I know so little about web security testing. The upside is there’s this codelab that I could explore further. Through the session, I also found out about a couple of interesting sites. One’s another site for learning about web app security — Web Goat — through which I came across an XSS cheat sheet. Another site was Cornify which was suggested as a more colorful and humorous alternative (imagine unicorns and rainbows on load) to pesky alert messages.

[Edit: July 17, 2013] I’m taking this Technical Web Testing 101 course by Alan Richardson on Udemy and found out that the Jarlsberg is now Gruyere (http://google-gruyere.appspot.com/).

Advertisements

Security fail

I came across an interesting bug the other day as I was trying to think of a good example of URL hacking. I entered the URL to our company’s online time sheet (OTS) http://192.168.4.135:8080/ots/Index.jsp onto my favorite browser and then backspaced a bit. I hit enter when the browser was pointed to http://192.168.4.135:8080/ots/ and ta-dah… a directory listing.

security_fail

Most interesting was that upon checking the contents of the folders, I came across a file with a .conf extension.  That made me do a double-take.  True enough, when I opened the file, it contained the DB server, username and password to our OTS. There was also a very helpful readme.txt file which cited the .conf file and the supposedly confidential information.  This has been fixed though that is, at least the access to the conf and readme files.  The directory listing can still be viewed. 😛