hacking with url rewriting

[irmoz]

Hi all,

I have a security problem with my website who is a social network (like facebook).
Let's me Explain :

You can execute this page on my website.
www.SocialNetWork.com/ChangeStatus.php?param=Hello
So your status become "Hello".

On your profile, you can create a link to a picture on the web, for example : <img src='http://www.hacking.com/pic.jpg'>

The problem is that a "hacker" create several russian girl profile and made links to pic.jpg on his server, and this .jpg file rewrite URL to : www.SocialNetWork.com/ChangeStatus.php?param=Suck.
So when you visite his profil, the php code is launched, and the status OF THE VISITOR is changed !

I have no idea of how to stop this ?
If i check the variable : $_SERVER['HTTP_REFERER']
The value is empty or www.SocialNetWork.com, but never www.hacking.com ...

How can i stop the fact that a foreign picture could launch a php page on my website ?

thanks for help !
ps: sorry for my english

[Ch0cu3r]

The russian user is performing a CRSF  and/or XSS attack.

 

You need to change the way you allow users of your site to change their status. For example you should only allow users to change their status from a POST request and you should issue a csrf token to prevent anyone from submitting a status value from outside of yoursite.

 

You also need to change how you validate external images your users are linking to. You need to check they are linking to an actual image, not a file with just a image extension on the end of the filename. For example one way to check if it is an image is to use getimagesize(). This function will return the image dimensions if it is a valid image. If its not a valid image it'll return false. If this happen you an reject image. 

[Jacques1]

There are actually two problems:

• You're violating the basic principles of HTTP.
• You have no protection against Cross-Site Request Forgery (CSRF) in place. Additionally, you may be vulnerable to Clickjacking.

First of all, visiting a URL (or in more technical terms: using the GET method) should not result in any significant data changes. The GET method is strictly for fetching a resource – hence the name. To change data, you need to use the POST method. Triggering actions directly through the URL may be convenient for you, but it's generally a very bad idea: What if the user reloads the page? What if they bookmark the URL? And of course it's very easy for an attacker to make the browser or the user visit the URL.

 

So before anything else, you need to fix those design errors. Then it's time to take care of CSRF protection: Right now, an attacker can trigger arbitrary actions of behalf of another user if they set up a form pointing to your site and then trick the victim into submitting this form. The user doesn't even have to actively click on a “submit” button. This can be done automatically with JavaScript, so merely visiting a page with is controlled by the attacker may be enough to fall victim to a CSRF attack. There's also a related attack called Clickjacking: The attacker embeds your site in a frame, hides the frame behind some fake GUI and makes the user interact with your site through this fake GUI.

 

There are several anti-CSRF techniques:

• You can generate a random token, store it in the user's session and include it as a hidden parameter in every form. When a form is submitted, you only accept the request if the token parameter is present and matches the token in the session. Due to the Same-Origin Policy, attackers generally cannot “see” the embedded tokens, so they are no longer able to forge a form poiting to your site.
• Instead of storing the token in the session, you can put it into a cookie. This has a similar effect. However, there are some caveats, so it's not recommended unless you fully understand the implications.

To protect yourself against clickjacking, there are again some techniques to choose from:

• Your webserver can set the X-Frame-Options header to prevent your site from being embedded in frames. This is strongly recommended, because it works fairly reliably in all common browsers.
• You can use a JavaScript-based “frame buster”. However, this obviously doesn't work if JavaScript is turned off. Depending on the technique, you'll either lose the protection, or the site will not be usable at all. So this approach really only makes sense if your site already requires JavaScript to be turned on.