Cross-site Request Forgery is a big problem in many of today’s web pages and applications and even tough its quite simple to exploit it can be very powerful. Lets start of with wikipedias definition of CSRF:

Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a type of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts.

While XSS relies on the victim to trust the web pages contents CSRF-attacks relies on the site to thrust the HTTP-request of a victim. Just by using social engineering to make a victim (that’s logged into a service, lets call it “safemail”) visit a malicious web page we can send requests to “safemail” via the visiting users session.

One of the most simple attacks is to embedd a GET-request in the src-attribute of an img-element, for example “http://www.safemail.com?a=logout”. You can also set the width and height to 0 pixels which will make it invisible so that the victim will be non the wiser. When the victim visits this site he will get logged out from safemail if it has no protection against these kind of attacks.

POST-requests are a little trickier than GET-requests. I find that the most effective and discrete way to do this is by using javascript to submit a form placed inside an, thanks to CSS, invisible iframe using this one-line code:

document.getElementById("csrf-form").submit();


There are a number of techniques to prevent these kind of attacks, some are more effective than others. I wrote a couple of functions in PHP to generate a unique token that is stored in the users session and placed in the GET or POST request and then compare the two values:


session_start();


function CheckToken(){
if($_REQUEST['check'] === $_SESSION['check'])
return 1;
else
return 0;
}


function GenPostToken(){
$token = md5(uniqid(rand(), true));
$_SESSION['check'] = $token;
return “<input type=’hidden’ name=’check’ value=’”.$token.”‘>”;
}


function GenGetToken(){
$token = md5(uniqid(rand(), true));
$_SESSION['check'] = $token;
return $token;
}

Thats all for me. You can read more about CSRF, XSS and web related security on:
http://ha.ckers.org/
http://www.milw0rm.com/papers/173
http://www.milw0rm.com/papers/182
http://www.businessinfo.co.uk/
http://www.mightyseek.com/

/ swampy

Do you remember the dark ages? When every executable file was like opening pandoras box. We where in desperate need of digital signatures for executable files, or so we thought.

Virus signatures has gone from 100k to 500k in just a short period of time and the number of threats trough XSS, injections, broken auth etc has exploded in the last couple of years. So why did file infectors stopped being a serious problem a few years ago? Did the A/V industry found a miracle cure for viruses? Was it the modern OS running in protected mode?

It’s a simple matter of user habits, a change in logistics trough modern file sharing. People simply do not exchange executables that often as 10 years ago. Today, people rather download an executable from the web rather than copy it from a friend’s computer. The way collective and modern file sharing is setup it’s simply impossible to spread a binary virus in the wild.

There were no new A/V technology or mass signing of files and the protected mode of any OS is still not really a binary virus killer. The binary virus simply became outdated in the process of human interaction along with the BBS and other ancients. Collective sharing truly killed the binary virus.

/ itcommie