Blog:tech
This is a simple tech blog. I am mostly interested in application security, web, technologies... but every time I can, I try to play with some other field I like such as data-mining, graph theory, compilers, languages, etc..Contact:
This a really nothing to do with web application security, but a friend asked me how to protect a bunch of html files in a directory. He was looking for sessions based solutions but for this he would have to rename the html files in php or whatever and then, implement the protection... pretty boring!
I suggest him a really easy and not perfect solution: checking the referer when accessing the html files (this is the kind of protection as the images anti-thief):
# .htaccess
# -------
RewriteEngine on
RewriteCond %{HTTP_REFERER} !.*yousite.com/.* [NC]
RewriteRule ^(.*)$ /fail.html [NC]
You can find an example here.
PS: this could not be a valid solution for lots of application!
Romain | Friday, March 9 2007 - 10:44 UTC | Discussion
The W3C announced yesterday that a new Working Group was created for working on the HTML language.
I don't know if you think the same way than me about this, but for me, HTML language is such a pain in the ass for security. It allows too much things, modifications, ill-written html... With XHTML we have the opportunity to have a quite strict language which is definitely better...
Please guys, when you are doing the new HTML think with security in mind, thanks.
For almost a week, I've been working with zeno, wisec and others on JavaScript events and HTML Tags; what event can be executed in what tag...
The testing is definitely not finished but I was implementing a JavaScript Unit Testing based test bed for keeping everybody out of clicking on 8700 testcases * nb_browsers...
Anyway, the method I use is to fire a JavaScript event on the load of the document to verify if it works (the information are gathering by the JSUnit Framework).
So, the funny part in firefox is that I can fire almost every event in every tag; you can find an example here where I do something like that:
<acronym onsubmit="alert('TEST')">test</acronym>
The equivalent Internet Explorer version can be find here (it works well... ie does nothing).
I didn't really take the time to think about this but I'm sure something can come from this...
Edit: Wisec found that under firefox you can also fire every events on unexisting tags such as:
<unex ondblclick="alert('TEST')">test</unex >
Romain | Friday, February 23 2007 - 08:10 UTC | Vulnerabilities
Yesterday, on the #webappsec channel, heanol asked how to do an XSS Injection in a anchor tag <a> without the style="expression(..)" referenced by RSnake in the XSS Cheat Sheet.
Then, I proposed him to use the JavaScript event onmouseover="" attribute... Thinking about this it's not really good because the victim has to put his mouse over this link which can be very small etc.
My idea then is to use CSS to make this link taking all the page: this is pretty basic but powerful!
<a href="the link" onmouseover="alert('XSS');"
style="position:absolute;top:0px;width:100000px;height:1000px;z-index:99999;" >Link</a>
I'll try to post some other CSS based interesting XSS injection...
The previous article on spam bots was focus on using generation of the document itself by adding dynamic content (JavaScript) or a random fields... By the way, Jungsonn follows with a clever technique of the same kind.
Today, I was looking at the logs of a phpBB forum we have in an association where we have lots of spam; okay phpBB is famous and maybe not the most secure but well... there is some prevention (modules such as CAPTCHA) for this and the webmaster installed lots of them...
I was quickly able detect manually the bots actually, this is something like same processes even if they introduced lots of variations and of course a detection system cannot be time based because they prevent this.
So we can easily see that it's tricky to automatically detect a bot without learning machine, SVM etc. but it's not my point here.
If I cannot easily prevent them coming on the website or track them, I can at least manipulate in some way:
Fake login page which cannot be seen by a user (<a href="login.php?sid=THE SESSION ID" style="display:none">Login</a>; As display:none can be easily detected by the bots we can trick this with the JavaScript "expression" evaluation in CSS...) and in the fake page adding some information in the cookie/session such as SESSION['BOT'] = 'DETECTED' etc.
We also need a verification script embedded in every page which would do generate a blank page or something like that... Don't forget also to ban the IP address.
I will try to develop this idea and test it because now, I have no proof that it can work properly. Furthermore, it also need the bots not to support CSS a/o JavaScript.
Romain | Friday, February 16 2007 - 14:11 UTC | Vulnerabilities
Months ago, I talked about the SVG file and the possibility to include JavaScript inside. Yesterday, I read on the blog of Disenchant that this needed XML Injection: that's true.
But then, I started thinking about variants of this and an embedded SVG
encoded with Base64 seems to work.
The injected string should be something like:
<embed src="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always" />
Edit:
You can also find it here now XSS Cheat Sheet.
Romain | Thursday, February 15 2007 - 13:23 UTC | Vulnerabilities
Definitely interesting stuffs:
http://www.owasp.org/index.php/Top_10_2007
This is a very good stuff for my current work at NIST on the specification for web app scanners...
Romain | Thursday, February 15 2007 - 11:32 UTC | Discussion
While reading the new post on Jungsonn's blog I decided to explain my point of view here.
Well, the background is around the news in the New York Times made by Acunetix (a Web Apps Scanner vendor):
70% of the websites scanned were found to contain high or medium vulnerabilities ..
I will not talk about the Joe Snyder declaration/bet which is kinda ... well sad for him :/
So, I guess the point of the discussion and maybe the misunderstanding between Acunetix, Joe Snyder, Jungsonn and the many others are the definition of basic words such as vulnerability.
First of all, I have to say that Jungsonn is right when he talk about the kind of vulnerabilities he focus on: let's say directly exploitable to generate some failure on the web apps.
But the point is that a vulnerability is not only this, it may also be really soft! If somebody is able to disclose some information on your website such as list files in a directory (directory listing), reach a sub-domain that he should not be aware of... All of this are vulnerabilities because somebody can get some information from it even if it's not directly exploitable such as remote file inclusion, sql injection etc.
And if I had a to use a Web Apps Scanner, I really need this tool to report all of this things because it should replace (for my company) the consultant team or the hiring of a security expert...
I really think this kind of discussion comes because we don't have a real taxonomy of this words and people have different thinking about security...
And of course I don't claim to have the truth, but at least that's my point of view...
If you have ever think about using a web application scanner for testing the security of your website, you certainly made a choice: Which web apps scanner should I buy/use ?
In this post, I will not tell you what is the better black box tester for whatever kind of web application.
The web applications may be very different, the tools are different and thus they could have different efficiency (i think it's non countable noun)... If you read this, you probably know that I am talking about scanners such as WebInspect, AppScan, Acunetix, Hailstorm, Pantera, Grabber... In the following sections, I will explain a main idea that should be used for testing such a tool.
A test suite for our tools is a website, this website has typically vulnerabilities; you can see this kind of website by watchfire, spi but also WebGoat, SiteGenerator or others. But all of these websites are not realistic and do not consider that the vulnerabilities may exist in different instances: variants.
If you don't know what is a variant check at the XSS Cheat Sheet (RSnake) or at the Attack Patterns (Sean Barnum). A variant is what the hacker use to perform his exploit.
A simple example for XSS is:
Let's say you protect your website against XSS by checking the <script> tag; this is not perfect and not good because there is some way to insert other type of XSS strings (onmouseover).
Here comes the concept of Level Of Defense. If you are a developer you think about filters, if you are an attacker you think about variants of vulnerability and attack patterns. The level of defense of a website is the strength of its filters again a given vulnerability.
For a SQL Injection you can have multiple type of filters... Here is a possible list of levels for the SQL Injection:
In the concept of the level of defense, it's important to not that depending of the type of vulnerability (weakness, failure...) the level n-1 is also performed in the level n or the level n is stronger (for the same variants) than the level n-1 (for instance, for Weak Hash Function it's not possible but using SHA-1 instead of MD5 is a level of defense higher).
A Key point:
When you are implementing a level of defense for a vulnerbility, you must be sure that your implementation does the whole thing for that type of filter. For example, if you are escaping the HTML entities, you need to do all not only '<', '>' and in the next LoD escaping ' and ".
With the level of defense, you can calibrate a type of website which may be close to yours; you can construct a test suite with your kind of level of defense and see how the tool detect the vulnerabilities when the LoD increase.
It is also a good way to know the state of the art of the tools for detecting vulnerabilities...
The idea was developed to create a test suite in order to evaluate web apps scanners; in this test suite we can select the current type of vulnerability and its level of defense (the hardness to break):

A couple of months ago, I had to make a Source Code Search Engine for the SAMATE Reference Dataset. The organization of our source code are not really common but still, it's easy to understand and organized.
I now release this tiny python script in the beta section: pyIndex.
You should have all the information you need to use/adapt this script for your own purposes; it uses a MySQL database and MySQLdb to connect to the database. The script is only for adding some words or references in the database, the search is not done (but it's only a really simple SQL
query...)
There is many ways to prevent spam from the bayesian tests (statistical tests) to the basic captcha
... But we all know that pictures captcha can be bypassed by OCR
even if it can be quite tough, there is some sofwtare and articles (example here).
Well, let's talk about 2 other ways:
Assuming that robots do not interpret JavaScript (which is probably true for most of the bots) it would be nice to have a hidden field filled by JavaScript. It's quite simple to make such a script:
var W3CDOM = (document.createElement);
var inputInserted = false;
function addInput() {
if (!W3CDOM || inputInserted)
return;
// create the input form
var hiddenInput = document.createElement('input');
hiddenInput.type = "hidden";
hiddenInput.name = "testBrowser";
hiddenInput.value = "success";
//now add the input to the DOM.
document.forms[0].appendChild(hiddenInput);
inputInserted = true;
}
Then, you test that the GET/POST('testBrowser') == 'success';
The input looks like that:
<input type="text" name="OneOfMyFields" onclick="addInput()" />
The idea is to create a form with one input which has different instances, let's say:
<input class='c1' type="text" name="login_1" value="" /> <input class='c2' type="text" name="login_2" value="" /> <input class='c3' type="text" name="login_3" value="" />
With your script, you choose a 'random' number from 1 to 3, create the good CSS
style (hide the not chosen value). The script store in the a cookie /SESSION/JavaScript the value of the random number then check after with this value.
If another input than the good one is filled than this should be a automated thing...
These techniques are absolutely not perfect at all, for the first, the assumption is quite odd I mean than it's not too hard to build a bot which can handle javascript/css/dom etc. and for the second, the 3 inputs are not enough, you need at least 30
for a representative trust.
What if - in some cases - a Web Application Scanner (black box tester) could tell you that you have this vulnerability/weakness in your code at this line?
Got some ideas this morning on this, I'll try to implement this in Grabber in the next weeks.
Today, I got a serious CSS bug with IE 6 (still don't know what's going on, maybe the HTML code is crappy...); anyway, just to say that I only have Internet Explorer 7 / Opera and Firefox and couldn't test/debug with Internet Explorer 6 (because there is no trouble with ie7).
I found that good stuff: Internet Explorer 6 Standalone version! Definitely useful...
That makes me think of a tool I can dream of... a kind of meta-browser that support lots of old/current standalone engines. Imagine with your firefox interface be able to load Internet Explorer5 or 6, Opera 8, Netscape 4, Lynx... that would be awesome for web developers/designers...
There is a firefox extension IE Tab which allows you to have the current IE engine in FF, but still, I need the old versions!
Romain | Friday, January 12 2007 - 07:38 UTC | Information
$8000-$12000 for a vulnerability disclosure in Internet explorer 7 or Vista ?
http://labs.idefense.com/vcp/challenge.php
Even if i'll be busy with papers and tests, I really would like to do different things:
For a while, I've been working on a test suite for evaluating web application scanners. Now I have a test suite (PHP/MySQL/AJAX) with a bunch of variable vulnerabilities:
But there is a problem for a full evaluation. Web Application are not only a simple schema of scripts and databases and complex relation, there is also server configuration, infrastructure, different type of databases etc. Thus, I really have to create different test suites for a good coverage of what web apps could be.
I plan to use:
This should cover the differnt type of application but I still have to think about server types, architectures,multiple databases etc.
One thing I really hate with the iPod is that the songs are pseudo-obfuscated in a hidden directory on the iPod. Therefor, we cannot, with iTunes, copy the mp3 from the iPod to the iTunes library (at least under windows) ... This is really stupid!
Anyway, there is lots of tools to do that and very well, but I decided to do one: an embedded one. The executable/script is on your iPod, then you can copy your files everywhere :)
iDumper is available in my beta/ repository.
Romain | Wednesday, January 3 2007 - 09:54 UTC | Vulnerabilities
I've just read it on Stefan Esser's blog: Stefano Di Palmo has disclose an XSS hole in the Acrobat PDF Documents.
Just to have a look at this you can go here: PDF and XSS under Google!
This vulnerability is really important, be careful when you're opening a PDF file...
All of these vulnerabilities in rich documents (FLASH, MHTML, SVG, Quick Time Movie, PDF, etc.) look like there is a big lack of security when people are designing this. Of course these are amazing documents and very useful, but with the so called Web 2.0 (and maybe the next web 3.0 with video broadcasting and much more) there is more and more holes.
What can we do? Think twice before creating web services with media documents?
This is not productive enough and maybe a little security lack is not really bad.Do we care if a couple of guys can steal some passwords...
I guess lots of people are thinking like that, this is understandable but truly not the right way.
I took some time this morning to extend the JavaScript parser; I also added a CSS parser.
The parsers can detect some basic comment based obfuscation. The JavaScript parser is also launched on the CSS's expression and url functions.
Now, I only have to parse the onbody, onmouseover etc. to get the JavaScript in these tags (samethings with the style tag for CSS); it should be done easily.
The following lines should be detected:
@imp/* This is a nested comment */ort('css-parser-nested-comment.css') </style>
The new Spider with the parser will be added in the next Grabber release.
I also have to say that I'm very proud that Simon Roses Femerling chooses to include the JavaScript/CSS parser from Grabber in the OWASP Pantera project :) !
Romain | Tuesday, December 19 2006 - 17:41 UTC | Information
You can reach the news from the SPI-Dynamics portal here:
http://portal.spidynamics.com/.../IE7-_2D00_-Phishing-vs.-Privacy.aspx
Basically, it shows that Internet Explorer 7 sends information on what you are currently browsing to a microsoft site with SOAP. Isn't it scary ?
For a study I'm looking for some "famous" OpenSource web application in PHP.
The two first I have selected are two CMS:
I also need to select some well known application, I can think of twatch, phpmyvisites etc. but I really have to make my mind of any restriction on the application I need to "test".
Romain | Sunday, December 17 2006 - 17:38 UTC | Information
I had some trouble with this blog, I was thinking it was because this is a dotclear2 beta version, but the tags and the rss links didn't work.
Then, I upgraded to the last beta version... same thing. The problem was actually the URL rewriting in Apache. It should be good now.
This afternoon I went to wikipedia and saw a SVG file. Then, I was thinking.: SVG... XML... Some minutes later, after a quick look at the spec. and especially the "Scripting" part, I had a SVG file with a XSS attack inside. Then I started to look at websites and advanced webmails for inserting my file.
Damned, I came something like one year too late... Wikipedia still does not allow to upload SVG files, Gmail does not open it hotmail itoo, and actually this thing is well known. Actually I've never seen any attack with some SVG files inside.
Okay, before Firefox 2.0 (and the next browsers) there was only external plugins for reading these files, It may change now. I'll keep on trying to do some things with my file!
Okay, all this SVG things are not new, but I'm a nioob in web security, at least it's new for me ;)
I've just found another commercial web apps scanner: "Acunetix Web Vulnerability Scanner".
You can reach it here: http://www.acunetix.com
I usually do not quote or report some tools, but I tried the trial version which seems to be nice, but not more than WebInspect or AppScan.
But while watching the tiny tools in the distribution, I saw an interesting file: RSnake_XSS cheat sheet.xml
This tool has a Fuzzer which performs some attacks from the XSS cheat sheet from http://ha.ckers.org and this is very interesting (this cheat sheet is something like the most relevant XSS attack dictionary).
Yesterday, I was testing some web apps scanner with my Test Suite (this test suite aimed to represent the actual common website: PHP, MySQL, CSS, JavaScript,AJAX) and what I really fear happened.
Most of them does not read the JavaScript and then... nothing.
I was only trying to catch the 14 possible SQL Injection which are all behind a AJAX Login system. The basic tools (like Grabber for instance) don't have a login mechanism but it's okay, the script names are in the JavaScript! A tool like Wapiti handle the cookies, but because it does not support the dynamic auth login, I cannot retrieve the cookies with its "getcookie.py" tool. I should have to create these cookies manually to bypass the login system...
Anyway... to make them feel better with the results I have to:
Another point about the first results I can see... a tool like Paros allows you to make lots of intereseting action because it's a proxy tool (you set it as a proxy into your browser then it save the actions you see, this is okay for the AJAX etc.). But when I looked at the results (for the SQL Injection only) it seems that it simply tag each parameter with the SQL Injection vulnerabilty (even if the parameter is only used by is presence in the URL), I was a little bit confuse about this...
I used to do craps with the Grabber distribution. Sometimes you could not use the soft at all...
It should be fixed now. The version seems to be quite "stable".
What's new in Grabber ?
« previous entries - page 4 of 5 - next entries »
Last comments