Post by Chris on Apr 6, 2009 16:42:19 GMT -8
I've been seeing several threads that refer to this specific Proboards error where it is automatically assumed it's coding errors. The person helping will have the user change this and that and the other thing until suddenly they scream "Eureka! it works now!". What they don't realize is by having the user change all these things they will most likely reuse or close the tab with the erroring form then when they reopen the form it will have a brand spanking new random hash.
I stand corrected
If there is an IMG tag on the page with an empty SRC, the browser treats it as a relative URL and sends a request to Proboards for the non-existent image, but the way the request is formed fools Proboards into thinking it's a request for a page load returning a new rand cookie value along with the entire HTML for the page.The browser discards the response data since it is not an image but the new cookie is applied thus causing unmatched values between form and cookie!
Proboards fails to check the requested MIME type (e.g. Accept: image/png,image/*;q=0.8,*/*;q=0.5) and just simply 404 the request. Instead Proboards resends the page HTML in response to an image request along with a brand new set-cookie header (rand cookie thus gets a new value)...
The hash value in the "rand" cookie is also repeated as an hidden form element (document.modifyForm.rand.value for example) and is sent back with the form to authenticate the submission came from an official Proboards form and not something else. If that rand value doesn't match the cookie then the submission is rejected.
Steps to Reproduce:
Explanation:
Each time Proboards sends out certain forms it generates a hash with it to be used for subsequent authentication. I've come across 3 forms with this hash: modify profile, header/footer and register. Loading any of these forms will generate a new hash which will make any previously obtained hash stale (invalid). You could load one of the other forms as TAB1 and/or TAB2 (mix and match) in the reproduce procedure and still get the error. You can even add the NOHEADERS=1 param to the url to rule out coding (TAB1 first then TAB2) and still get the error.
When TAB2 opens TAB1 becomes useless either because the "rand" cookie now contains a new hash which doesn't match the hash on the hidden form element or simply because Proboards saves the latest hash server side for comparison, I haven't really done any tests to determine which.
When a user encounters this error it is because they have opened one of the authenticated forms after opening the the form now giving an error. Edit:(see above for alternate reason)
Edit
I just did an experiment by going through the reproduce procedure but before submitting TAB1 I edited the cookie and changed the value back to the hash on TAB1 and the form submitted with no problem. I then opened only a single tab to an authenticated form and changed the cookie value then submitted and got the error. Conclusion: the problem occurs when the random value on the form doesn't match the random value in the cookie and not some server comparison hash. Now it makes sense why the rand cookie was given hidden status.
Edit
To put it another way, before the rand cookie was made httpOnly, a patch script could have been written that would check the value of the random element on the form against the random value in the rand cookie at submission time and overwrite the cookie with the correct value if not matching. This would however defeat the purpose of authentication since any code could do this to fake a form. Making the rand cookie inaccessible to scripts was a good security move but made it impossible to address the case where the rand cookie was overwritten by opening a new form (that also authenticated) making the random value on the old form useless since it no longer matched the cookie value.
I stand corrected
If there is an IMG tag on the page with an empty SRC, the browser treats it as a relative URL and sends a request to Proboards for the non-existent image, but the way the request is formed fools Proboards into thinking it's a request for a page load returning a new rand cookie value along with the entire HTML for the page.The browser discards the response data since it is not an image but the new cookie is applied thus causing unmatched values between form and cookie!
Proboards fails to check the requested MIME type (e.g. Accept: image/png,image/*;q=0.8,*/*;q=0.5) and just simply 404 the request. Instead Proboards resends the page HTML in response to an image request along with a brand new set-cookie header (rand cookie thus gets a new value)...
The hash value in the "rand" cookie is also repeated as an hidden form element (document.modifyForm.rand.value for example) and is sent back with the form to authenticate the submission came from an official Proboards form and not something else. If that rand value doesn't match the cookie then the submission is rejected.
Steps to Reproduce:
- open a tab to a modify profile page [TAB1]
- open a new tab to another modify profile page [TAB2]
- go back to the original tab (TAB1) and submit ("Authentication" error occurs)
Explanation:
Each time Proboards sends out certain forms it generates a hash with it to be used for subsequent authentication. I've come across 3 forms with this hash: modify profile, header/footer and register. Loading any of these forms will generate a new hash which will make any previously obtained hash stale (invalid). You could load one of the other forms as TAB1 and/or TAB2 (mix and match) in the reproduce procedure and still get the error. You can even add the NOHEADERS=1 param to the url to rule out coding (TAB1 first then TAB2) and still get the error.
When TAB2 opens TAB1 becomes useless either because the "rand" cookie now contains a new hash which doesn't match the hash on the hidden form element or simply because Proboards saves the latest hash server side for comparison, I haven't really done any tests to determine which.
When a user encounters this error it is because they have opened one of the authenticated forms after opening the the form now giving an error. Edit:(see above for alternate reason)
Edit
I just did an experiment by going through the reproduce procedure but before submitting TAB1 I edited the cookie and changed the value back to the hash on TAB1 and the form submitted with no problem. I then opened only a single tab to an authenticated form and changed the cookie value then submitted and got the error. Conclusion: the problem occurs when the random value on the form doesn't match the random value in the cookie and not some server comparison hash. Now it makes sense why the rand cookie was given hidden status.
Edit
To put it another way, before the rand cookie was made httpOnly, a patch script could have been written that would check the value of the random element on the form against the random value in the rand cookie at submission time and overwrite the cookie with the correct value if not matching. This would however defeat the purpose of authentication since any code could do this to fake a form. Making the rand cookie inaccessible to scripts was a good security move but made it impossible to address the case where the rand cookie was overwritten by opening a new form (that also authenticated) making the random value on the old form useless since it no longer matched the cookie value.
