I'm thinking about including it in my master thesis, but I wanted to get some reliable comments before working on it seriously (sorry for my English, I hope someone will understand what I meant):

While playing with mhtml vulnerability and other cross domain attacks, I started thinking of using unpredictable URLs as a part of defense. It can be easily achieved by adding session id to URL - but from other security reasons it can't be the same as the cookie session id. So what about using two session ids: one in cookie, other inside URLs?

It has any sense only if you have to put that session id into URL to have it appended to relative links on the page - otherwise, it offers no protection (because it can be read with e.g. IE mhtml vulnerability).

User is considered valid if both session ids are correct and belong to the same session.

The first problem with such protection is the need to login in each browser tab/window independently (unless user logged in before opening additional tabs/windows).

Some primitive PHP code to show what I am thinking about:

<?php
/*********************************************
* Double session id against cross domain leaks
*********************************************/

session_start();
require_once('functions.inc.php');

if ( isset($_POST['login']) && isset($_POST['password']) && checkIfLoginCorrect($_POST['login'], $_POST['password']) ) {
session_regenerate_id();
if ( !isset($_SESSION['url_id']) ) {
$_SESSION['url_id'] = generateNewURLSessionId(); //different from cookie session id
}
header('Location: '.getCurrentPageURLWithParam('url_id='.$_SESSION['url_id']));
exit;
}

$logged_in = false;
$url_id = '';
if ( isset($_SESSION['url_id']) && isset($_GET['url_id']) && $_GET['url_id']===$_SESSION['url_id'] ) {
$logged_in = true;
$url_id = $_SESSION['url_id'];
}

if ( checkIfPageRequiresValidUser() && !$logged_in ) {
showLoginPage();
exit;
}

addParamToAllRelativeURLsInTemplate('url_id='.$url_id);

showCurrentPage();

?>

What do you think? Are there other problems with double session id that I did not though about?

I have a very simple comment - what if the user clears their cookies or doesn't accept them?

Second and more serious problem, how did they find that URL in the first place? If it's find-able, it's XMLHttpRequest find-able.

- RSnake
Gotta love it. http://ha.ckers.org

I got some sleep and it doesn't seem like a good idea now. For example, it would also need to have all outgoing links converted into redirects. I'm trying to find a solution that could be relatively easily added to existing cookie-based authorization.

You are absolutely right about XMLHttpRequest, but that's the point. A page can be read with XMLHttpRequest in three ways:

1. by persistent XSS (the above solutions is not meant to protect against it)

2. by reflected XSS, e.g. http://example.com/param=<script>doSomething();</script>
If you inject the script into a page without knowing url_id, the above solution assures there is no url_id on any page you can read by XMLHttpRequest. That's this part of code (checking $_GET['url_id']):
<?php
$url_id = '';
if ( isset($_SESSION['url_id']) && isset($_GET['url_id']) && $_GET['url_id']===$_SESSION['url_id'] ) {
$url_id = $_SESSION['url_id'];
}
addParamToAllRelativeURLsInTemplate('url_id='.$url_id);
?>
The only page that gives out url_id is the login page - but it does so by redirection, not by a XMLHttpRequest-readable value, so you still can't get it without knowing password.

3. by browser vulnerabilities like mhtml redirect in IE
Solution is the same as above.


As to the users not accepting cookies, it's true: they couldn't log in.



Edited 3 time(s). Last edit at 10/21/2006 06:08AM by lpilorz.

That might not be a problem for small websites, but for big ones this would nearly impossible to implement. Every function would have to be recoded to output links with these tokens in them. I mean, that's really how you solve CSRF, and for critical functions that makes sense to have them generate a nonce or ask for user input that is verifyable and not known by attackers.

However, generating every single link to every single function with a nonce from the login page on would be horribly complex and I'm not sure how much it buys you. Think of how many pages/functions there are on even this website, and this website is tiny compared to any social networking site. Sure, you might be able to force someone to edit their post via CSRF, but that's not nearly as bad as getting them to change their email address or some other function you'd want to protect against.

- RSnake
Gotta love it. http://ha.ckers.org

I see your point. Is there any "cheap" way to protect a site against vulnerabilities like that with mhtml?

By the way, I am curious, why that happens... From the following two pages, one is readable with mhtml vuln, the other is not:
http://lukasz.pilorz.net/string.php
http://lukasz.pilorz.net/index.php

I tested it by own code and http://sec.drorshalev.com/dev/ajax/gen.htm

AFAIK using URL rewriting for session ids is immune to CSRF attacks as long as the page itself has no XSS hole and the browser can be considered safe (no access to history, safe same origin policy, etc.). Same applies to hidden fields.
But both methods suffer from complexity rsnake explained. You also have to think about other draw backs like referer and links pointing outside your app.
So you have to decide if you want a cheap developer with a cheap solution for cheap applications, or something more secure ;-)

You know Lukasz, I really have no idea why one wouldn't work and one would... I thought maybe there would be something interesting in the header but no dice there. Frankly, I'm a bit stumped! Which one worked and which one didn't?

- RSnake
Gotta love it. http://ha.ckers.org

index.php did not work, string.php worked.

A few weeks ago I wrote a mhtml vuln test, based on Dror Shalev's one. After the same vuln was published for IE 7, I tried it again - and it didn't work. I tried many variants with changing headers and such, and it was yesterday I realized that the page I am trying to read is simply not readable by this method. It was index.html from the same domain.

I changed it into index.php and made the headers similar to string.php, but it is still not readable. It seems it has to be something in the html content itself. Unfortunately I don't have too much time this weekend, but I'll try to find it out soon.

Maybe it could provide some solution to protect other pages (only from this particular vulnerability, but it would be still a bit useful).

Eureka!

mhtml reads from the first double line break to the end of the document. Look at the Secunia test case: where does the retrieved content start.

It seems, that removing all double line breaks from the page makes it secure from this vulnerability.

Edit: Or, like my father suggests from behind my shoulder, leave a double line break at the end, with some HTML-commented description of what you think of the fu.ckers trying.



Edited 1 time(s). Last edit at 10/22/2006 04:54AM by lpilorz.

It became quite obvious when I looked at the sample mhtml file. IE just treats everything up to the first double line break as MIME headers:


From: <Saved by Windows Internet Explorer 7>
Subject: MHTML - Wikipedia, the free encyclopedia
Date: Sun, 22 Oct 2006 12:52:30 +0200
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----=_NextPart_000_0000_01C6F5D8.EF4B0510"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C6F5D8.EF4B0510
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://en.wikipedia.org/wiki/MHTML

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" =
"http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML lang=3Den dir=3Dltr xml:lang=3D"en"=20
xmlns=3D"http://www.w3.org/1999/xhtml"><HEAD><TITLE>MHTML - Wikipedia, =
the free encyclopedia</TITLE>



Edited 1 time(s). Last edit at 10/22/2006 06:31PM by lpilorz.

wow, good work on finding that

-maluc

By the way, anyone that tested it probably knows already, but I don't think it was mentioned: mhtml trick does not let you read headers by getAllResponseHeaders(). I'm not sure why does it behave that way, but it's good news for the good guys.

If anyone spotted different behaviour, please let me know.

all it does is read the html source *starting at the first double line return* so a website like:

<html>
<head>
<title>i love free midget sex</title>

</head>
<body>
Hello Fellow midget pron lovers.
<img src="sexymunchkins.jpg" />

</body>
</html>

Will return something like:

</head>
<body>
Hello Fellow midget pron lovers.
<img src="sexymunchkins.jpg" />

</body>
</html>

So you can't see the cookies, and you can't see anything before the first 'double enter'. So if you want to make a page 100% secure.. remove all blank lines in the source. But it cannn read all tokens and all settings for a user whose logged in. For example, while i'm logged into my chase account (please don't try ^^) or have autologin enabled.. using CSRf to have me pull the site https://chaseonline.chase.com/colappmgr/colportal/customer?_nfpb=true&_nfls=false&_pageLabel=page_ecareprofile&p_returnUrl=page_customercenter .. and you'll be able to parse out my home address and cell phone number. Not to mention my email and credit card number. That's pretty dangerous - no need to make a convincing fake login page at chase-update.com or something.

I've had to put in alot of overtime work this week, but hopefully i'll post useful code soon :/ .. but with a local redirect it's a cinch to implement.

-maluc

Inserting a html comment like below to the top of the page will prevent the mhtml attack.

<!--
Content-type: multipart/related; boundary="==FxxkMS"; type="text/html"

--==FxxkMS
-->

Thanks.



Edited 1 time(s). Last edit at 11/16/2006 03:15PM by Kanatoko.

Interesting. Why is that? That in of itself feels like it might be an issue.

- RSnake
Gotta love it. http://ha.ckers.org

IE takes the body part of the HTTP response as "MHTML message".
First double line break indicates end of header.
IE ignores invalid header like "<!--", but takes valid header like "Content-Type: ...".

So I think some mhtml header can be used to hide the contents of the page.

<!--
Content-Disposition: inline; filename="FxxkMS.gif"

-->

Will also work.

I got some hints from this website.
http://dsv.su.se/jpalme/ietf/mhtml-test/mhtml.html

I think any double line break anywhere on the top of the page would work though, wouldn't it?

- RSnake
Gotta love it. http://ha.ckers.org

No, just the opposite.. it's the double line breaks that end the header and begin the info .. so everything after a double line break, the mhtml can read (nothing before it)

remove all double lines and you're secure. I haven't tested kanatoko's suggestion, but from what i've seen of mime formatting, i trust that it should work. Smart workaround..

Especially since it'll likely stay unpatched for atleast the next month ^^

-maluc

Interesting. I very rarely have additional newline characters in my own code (granted I use other people's code a lot).

If it remains un-patched one more month I think it's safe to say they aren't going to fix it and you should feel safe in writing code that uses it.

- RSnake
Gotta love it. http://ha.ckers.org

Well i cleaned up the half that uses a local redirect .. but the remote redirect is still buggy (power outage all 8-10hrs yesterday so was short on time) .. and ya, i was surprised to find this forum double-newline free when i checked it.

i don't have any such 'no new line' habits intentionally.. but i'm a stickler to following standard indentation. When some exploit comes out for a vulnerability in bad indenting - i'll get the last laugh ^^

-maluc

Hello

I found that the sample code in my old post ( November 16, 2006 01:07PM ) does not work properly.

I wrote...

1: <!--
2: Content-type: multipart/related; boundary="==FxxkMS"; type="text/html"
3:
4: --==FxxkMS
5: -->

We can't use -- in HTML comments. I didn't know that.
So line 4 is not valid.
More precisely, "==FxxkMS" in line4 and line5 are not treated as a comment. This is a problem.
I'm sorry about this mistake.

Alternative Solution:

<!--
Content-Disposition: attachment

-->

It works.
I have applyed this to my web application and tested that the MHTML redirection vuln couldn't read any informations from there.

No patch released yet ... :(



Edited 1 time(s). Last edit at 12/21/2006 01:40AM by Kanatoko.

I tested your code a few times, and the comments worked fine in FF/IE, but it's true, I also forgot about -- :) Thanks for the new solution.

Hi lpilorz

Thanks to your reply.
By the way, what version of IE do you use?

I have tested on IE 6 on Windows XP SP2 ( Japanese ).
I especially want to know whether this solution works on IE 7.

Lately IE 6 on Windows 2000 SP4, but I'm almost sure it worked in IE 7 too... Unfortunately I can't check it at the moment (I could, but only on Vista, so it's worthless for testing this vulnerability).

Can I steal session id ( in cookie ) using the MHTML bug?
Is there any way to do that?

--
Kanatoko
http://www.jumperz.net/

No you can't. The MHTML bug gives you read access to a specific page (effectively what XHR gives you).

Thanks christlan.

But what happen if a website uses session id as a CSRF-token in a form tag?

Please read pdp's article:
http://www.gnucitizen.org/blog/preventing-csrf

If you had read that article attentively, you'd have seen that I've already commented pdps statement. What I wrote should answer your question.

Any token embedded in the html source code can be picked up.

What I want to say is that
in normal situation, an attacker CANNOT hijack the session using the MHTML bug because he can't steal the session id.

But pdp's statement enables an attacker to steal the session id using the MHTML bug.
The system will be vulnerable not only to CSRF, BUT ALSO TO Session Hijack.

So using the session id also as a CSRF-token is very dangerous and should not be implemented.

Please stop pdp lol

--
Kanatoko
http://www.jumperz.net/