Protecting your site from form tampering....
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
And of course we've also gone seriously astray from my OP concerning protecting a form from a person with access to the view source and the ability to arbitrarily alter it and post it back. (Detecting that a form didn't come from your own server is tough as the attacker gets more sophisticated therefore my focus changed to helping to detect if the form had been tampered with rather than its origin)
I'm still interested in the CSRF discussion though, too.
I'm still interested in the CSRF discussion though, too.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Hmm, once you put it that way, I'd say this... what kinds of forms would act this way? People can do certain things and are not allowed to do other things, and regardless of whether or not the server originally issued the form, as long as a POST request wants to do something that the current user (whether logged in or not) is allowed to do, then the server does it. Methinks it's just a matter of permissions.
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.
Also, how can a resource in one tab obtain data within the source of another tab? That would be a major browser vulnerability, and I've not heard of such a thing. The closest thing I can think of is the vulnerability where the stuff you type appears in a form that has taken focus, even if that form is in another tab. This has been fixed, and it never seemed like a huge deal to me anyway.
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.
Defense in Depth, Never Trust Anything Coming From the User
Hashed tamper-codes directly apply to the trust issue; and add a layer to the DiD. Yes everything should still be verified and validated 6 ways to wednesday, but this is a type of "attacker" visible device that can help "scare" off... If you're a low profile target, and you look hard to crack, they'll just move along some of the time....
Hashed tamper-codes directly apply to the trust issue; and add a layer to the DiD. Yes everything should still be verified and validated 6 ways to wednesday, but this is a type of "attacker" visible device that can help "scare" off... If you're a low profile target, and you look hard to crack, they'll just move along some of the time....
Perhaps this should be a different topic? If so, please start it. :-)nielsene wrote:I'm still interested in the CSRF discussion though, too.
I apologize if my posts have been off-topic. I thought we were discussing form spoofing, which is a topic where I think CSRF fits nicely - it's the only actual concern, in my opinion, since spoofing a form otherwise only allows an attacker to bypass client-side restrictions, something we should never depend on anyway.
Apparently JavaScript form.submit() has been blocked by Internet Explorer (default config). But it seems to work in Firefox...
Then i thought about using XMLHTTP but it appears Microsoft has already bugfixed that.. http://support.microsoft.com/default.as ... US;q318203
Then i thought about using XMLHTTP but it appears Microsoft has already bugfixed that.. http://support.microsoft.com/default.as ... US;q318203
Firefox refuses to open the XMLHTTP... But IE gives a little pop, which most people simply click away with YES... (tested from http://test... requesting object at http://timvw.madoka.be)
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>The thread started out with a discussion of protection from an active/curious malicious user, not from an innocent intermediary. The CSRF vulnerability is, in some sense, a subset of the initial thought. The difference between an active evil and purely "passive" messenger.
I thought I had heard of a full OS implementation in JS(with full read permissions to the filesystem), so I thought that anything an OS could do was doable in JS. If that's wrong then I'm less worried about CSRF and would agree that the token method (when used as a nonce as already also mentioned) would be adequate protection. I'm still unsure, not knowing enough about JS's limitations/capabilities. If JS has any method for getting at the cache its game, set, match. If it can get at the source for other open tabs or windows, ditto. If not, then yes it should be ok.
I was realizing on the drive home, that it comes down to at one level, the ability to distinguish between user initiated or computer initiated requests, which in general is an intractable probleem unless the "type this word/number" style code is used on every form submission. (Assuming a non-trojaned browser, in which case all bets are off.).
I thought I had heard of a full OS implementation in JS(with full read permissions to the filesystem), so I thought that anything an OS could do was doable in JS. If that's wrong then I'm less worried about CSRF and would agree that the token method (when used as a nonce as already also mentioned) would be adequate protection. I'm still unsure, not knowing enough about JS's limitations/capabilities. If JS has any method for getting at the cache its game, set, match. If it can get at the source for other open tabs or windows, ditto. If not, then yes it should be ok.
I was realizing on the drive home, that it comes down to at one level, the ability to distinguish between user initiated or computer initiated requests, which in general is an intractable probleem unless the "type this word/number" style code is used on every form submission. (Assuming a non-trojaned browser, in which case all bets are off.).
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.