Entries tagged as javascript

Test your browser for Clickjacking protection

Thursday, September 9. 2010, 00:22
In 2008, a rather interesting new kind of security problem within web applications was found called Clickjacking. The idea is rather simple but genious: A webpage from the attacked web application is loaded into an iframe (a way to display a webpage within another webpage), but so small that the user cannot see it. Via javascript, this iframe is always placed below the mouse cursor and a button is focused in the iframe. When the user clicks anywhere on an attackers page, it clicks the button in his webapp causing some action the user didn't want to do.
What makes this vulnerability especially interesting is that it is a vulnerability within protocols and that it was pretty that there would be no easy fix without any changes to existing technology. A possible attempt to circumvent this would be a javascript frame killer code within every web application, but that's far away from being a nice solution (as it makes it neccessary to have javascript code around even if your webapp does not use any javascript at all).
Now, Microsoft suggested a new http header X-FRAME-OPTIONS that can be set to DENY or SAMEORIGIN. DENY means that the webpage sending that header may not be displayed in a frame or iframe at all. SAMEORIGIN means that it may only be referenced from webpages on the same domain name (sidenote: I tend to not like Microsoft and their behaviour on standards and security very much, but in this case there's no reason for that. Although it's not a standard – yet? - this proposal is completely sane and makes sense).
Just recently, Firefox added support, all major other browser already did that before (Opera, Chrome), so we finally have a solution to protect against clickjacking (konqueror does not support it yet and I found no plans for it, which may be a sign for the sad state of konqueror development regarding security features - they're also the only browser not supporting SNI). It's now up to web application developers to use that header. For most of them – if they're not using frames at all - it's probably quite easy, as they can just set the header to DENY all the time. If an app uses frames, it requires a bit more thoughts where to set DENY and where to use SAMEORIGIN.
It would also be nice to have some "official" IETF or W3C standard for it, but as all major browsers agree on that, it's okay to start using it now.
But the main reason I wrote this long introduction: I've set up a little test page where you can check if your browser supports the new header. If it doesn't, you should look for an update.

More XSS

Friday, July 13. 2007, 04:28
I thought I'd give you some more (all have been informed months ago):

http://thepiratebay.org/search/"><script>alert(1)</script>
http://www.gruene.de/cms/default/dok/144/144640.dokumentsuche.htm?execute=1&suche_voll_starten=1&volltext_suchbegriff="><script>alert(1)</script>
http://www.terions.de/index_whois.php?ddomain="><script>alert(1)</script>
http://www.eselfilme.com/newsletter/newsletter.php?action=sign&email="><script>alert(1)</script>
http://www.region-stuttgart.de/sixcms/rs_suche/?_suche="><script>alert(1)</script>
http://reports.internic.net/cgi/whois?whois_nic="><script>alert(1)</script>&type=domain

XSS on helma/gobi

Thursday, July 12. 2007, 00:44
I still have some unresolved xss vulnerabilities around. It seems to be common practice by many web application developers and web designers to ignore such information.

This time we have gobi, a cms system based on the quite popular javascript application server helma.

http://int21.de/cve/CVE-2007-3693-gobi.txt

More to come. As this xss stuff is far too easy (try some common strings in web forms, inform the author, publish some weeks later), I think about doing some kind of automated mechanism to search and report those vulnerabilities.

XSS der Woche

Thursday, March 15. 2007, 00:43
Ich wusste doch immer dass die von der Filmindustrie das mit dem Internetz nicht verstanden haben:

Browser-Spielchen

Saturday, March 10. 2007, 02:47
Ich bin ja bekennender KDE und Konqueror-Fan, aber ein zentrales Feature fehlt: Das DHTML-Lemmings läuft hier nicht, weswegen man Firefox bemühen muss.

Escapa! ist auch sehr nett und läuft auch im Konqueror.

Best viewed with any browser?

Sunday, February 11. 2007, 00:42
Now, if you've been on the internet a bit longer, you may remember those sites at the end of the 90s telling you that they're »best viewed with a resolution of 1024x768 and the Microsoft Internet Explorer version 6.0". Luckily, most of those pages disappeared with the upcoming success of Mozilla Firefox and others (oh, there are still some, e. g. the cinema in my home town, but ie6 runs on wine).

As you may know, I'm a happy KDE user and have been using Konqueror as my everyday browser for some time now. Recently, I discovered more and more pages I couldn't use any more. I had to start this thing called Firefox. I don't like it, but that is not the point here.
I even noticed today that ebay has a new interface that konqueror doens't like.

This is a result of the more and more upcoming AJAX/JavaScript-stuff, which is often nice, I saw a lot of well designed web applications lately (ok, I saw a lot of crap, too). I'm not enough into JavaScript to know if it's the lack of support by Konqueror or the pages. I just hope that people will come together and find solutions for that. I remember that there was some discussion about using webcore (the khtml-fork used by apples safari) for konqueror, don't know if that would make it better, maybe some users of this drm-crippled system could comment on that.
(Page 1 of 1, totaling 6 entries)