Operation n

Just to give our readers a heads up, you would have noticed Wooshy has joined in the project and has been releasing some cracking content.

What’s more, michaeldaw . org has been evolving for some time! Ive been tossing and turning in my bed at night and in my mind during the day to try find a domain name to match MD’s future vision. In short, stay tuned because we are taking this baby all the way :)

No it’s not about stalking, this time. But trust relationships are firmly on my mind and I ain’t talking about my private life neither!
As you may know there’s lots of trust relationships in computing. Those of you who love Microsoft would know about trust relationships from back in the day. And to me, they are truly something to think about (and has been thought about) when dealing with web applications and weaknesses in them. As well documented, cross domain security issues relating to iframes and recently htmlrequests (xmlhttprequest). The latter allows absolute URLs in the open method. However, it’s almost useless and rarely used now as URIs are converted into the domain that the page resides from.

For an attacker (or in my case, developing a proof-of-concept) to exploit XSS so that information (e.g. cookies) is sent to the attacker’s site, the httprequest looks like it is blocked. The standard XSS-phishing site attack will always be available but this requires user intervention (or dumbness). However, the question is “Can you still make a XSS script attack to automatically upload information?” With iframes and httprequests obviously out of the question, this looks hard! Though, I can still think of 3 or 4 ways around this, I need to try them out first. But let’s just say, you have to go oldskule for most of these ideas. Mind you, if you and I can think of any, they are probably blocked…

On the flipside to this, this makes it very awkward for sharing information between sites on-the-fly, which is the key to web2.0, (social networks, blogs, etc). The work around is to incorporate sharing information techniques in server-side scripts rather than client-side. This could be opened up slightly by having… yes you’ve guessed it… “trust relationships”. A site could instill certain friendly domains as part of the server-side scripts to client browsers. The problem with this though is, it has to be enforced that the trust domains cannot be changed at the client.

I found this interesting site on XSS. It’s a good tutorial if you want to show a newbie/novice something. And certainly demonstrates XSS and cookie stealing quite handily.

http://www.steve.org.uk/Hacks/XSS/index.html

It’s a bit thin on the xss filtering side. There really should be a white paper on XSS filtering techniques. If not, why the hell not! The following looks like a good start…

http://www.ihtb.org/security/xss_hacking_exposed.txt

This is taken from a newspaper a week or two ago… And I would have used its title ‘Facebook doggers suspended’ but you may get the wrong idea!

Two pupils have been suspended from a private school after they were found to be members of a ‘dogging’ group featured in facebook.
The Reigate Grammar School students were punished after adding their details to the Reigate and Redhill Institute of Midnight Dogging page on the networking site.
The group suggests ‘dogging spots’, where couples and groups carry out sexual acts in public places. But school staff said they were confident the pupils had not taken part in any lewd acts.
Now, the 3800 pound-a-term school which counts comedian David Walliams and DJ Fatboy Slim as former pupils is warning pupils of the dangers of social networking sites.
Staff said the students, who have been named, were suspended for bringing the school into disrepute.
They have since terminated their membership of the group, which was founded by a former pupil.
The group was created by James Lindley, who left Reigate Grammar two years ago. In one post on the group’s site, he declares that a mini metro is the best bonnet to ‘do go’.
A spokeswoman said: “We are deeply disappointed to ear of any negative association by a past student”

Some cross-site scripting (xss) attacks only occur when you are logged in. Now one corporate web content management system that I was testing, did not appear to have any significant vulnerabilities listed on any of the main security sites. So I was a bit surprised to find a XSS issue in accessing the profile of an uploaded file.

Now this got me thinking. As this is a corporate application and you need to be authenticated to see it, the general hacker will arguably not able to see it (unless they are familiar with the application or have tested it) and hence no listing on the main security vulnerability sites. However the problem is if a vulnerable hyperlink can be sent to someone, after they log in, they may encounter the XSS (if the login just redirects the user with no filtering).

Also another concern is making an Intranet web application, available to the Internet. Naturally, there would be some form of accounting an authentication. But more than likely, there would some security issues relating to the web application (well my experience would suggest that they are some issues than don’t get covered in a more ‘relaxed’ Intranet web application) that would make it vulnerable. Of course there is the network infrastructure to think about as well, using DMZ and encrypted security protocols. So in general, companies should tread carefully when making the transistion and call in a mr pentester… heh!