Hi, I believe this bug is a critical security issue: When a form contains hidden fields like this code below PAGE 1 (reduced set from the above url), and if the page resulting for the post has a javascript back window.history.go(-1) (like the PAGE 2 below), then PAGE 1 is reloaded from server like PAGE 3 below, but then WEBKIT and SAFARI *change the DHTML HIDDEN FIELDS values* to the previous values from PAGE 1 ! like follows: 1) safari refetches the PAGE 1 from the server if page has 'do not cache' attribute, which is ok. 2a) safari auto-fills in the form with the previous values (except for password-type fields), that's ok too 2b) safari also auto-fills (overrides !) the hidden-fields types. THIS IS NOT OK AND A CRITICAL SECURITY ISSUE. You can easily reproduce this behavior with Sept 10th nightly-build or Safari 3.1.2 and check in Firefox that it's ok, using the above URL: http://www.joomlapolis.com/component/option,com_comprofiler/task,lostPassword/ a) check the box "Lost username" b) write-down the captcha image you get there (this is renewed at each page reload) b) fill-in any email into e-mail address, e.g. "abc@def.com", ignore the ajax email checker result. c) fill-in a wrong security code, e.g. "abc" d) click on "Send username" button. e) see the javascript popup, including history(-1) f) see that you are comming back to previous page with captcha image updated (the url of the image contains the same session-id as in the hidden field) g) click again lost username h) type-in again same dummy email address into email field i) this time, type in the CORRECT captcha code from current image j) see that the javascript popup says invalid ! k) do steps g)-h) again, but this time with the very first captcha you wrote down in step b) l) see now it works: instead of first test of captcha code failing, you get another error message for inexistant email (2nd test webserver-side). m) If you reload full page, then put correct captcha code, it works, since page-reload does not override the hidden field. n) if you then hit back button of safari, and try again, it will not work either. Reason is that BACK button has same effect than javascript:window.go(-1). This is due to fact that the hidden field is sending the hidden field (session id) of the very first form displayed in step a) !!! FIX proposal: same as PASSWORD-type fields, HIDDEN-type fields should not be populated on a "BACK" event in forms. Ok. Now why we believe this is a critical security issue ? : - a user hitting the back button in a browser experiences the same problem. - some websites encode session tokens identifying a logged in user in a hidden form field, as 1-5 measures of sessions-security. - if a user leaving browser window open, then another user could get logged-in if that's the main/only security protection of a site, just by hitting the back button. Please use following CREDITS TO DISCOVERY: "The Community Builder team at www.joomlapolis.com" (do not use my professional address, and don't publish this report, also after fixing). We are an open-source project, and are reporting this privately here, so you can fix this issue. Thanks for confirming me at my email that you received this security report and when you are planing to fix it. Safari rocks and WebKit is the best open-source webbrowser engine, keep the good work going :) Thanks, Beat PAGE 1: <form action="http://www.joomlapolis.com/" method="post"> <label>Enter username:</label> <input type="text" name="checkusername" /> <label>Enter Security Code:</label> <input class="inputbox" type="text" name="captchacaptcha" /> <input type="hidden" name="captchacaptchasid" value="pS3aqna1ftpyDxEa8vWdS6cyLH1ItRdF" /> <input type="submit" class="button" id="cbsendnewuspass" value="Send Username/Password" /> </form> PAGE 2: <script type="text/javascript">alert('error: e.g. wrong code'); window.history.go(-1); </script> PAGE 3: returned by website after the PAGE 2 BACK event to PAGE 1 URL: SEE THE DIFFERENT HIDDEN FIELD !!! : THAT GETS OVERRIDEN BY PREVIOUS POST IN THE DHTML WHEN PREVIOUS POST DID A window.history.go(-1) !!! : <form action="http://www.joomlapolis.com/" method="post"> <label>Enter username:</label> <input type="text" name="checkusername" /> <label>Enter Security Code:</label> <input class="inputbox" type="text" name="captchacaptcha" /> <input type="hidden" name="captchacaptchasid" value="mG0OE0BjcTMfuEjzl396bg23zvYRLzHq" /> <input type="submit" class="button" id="cbsendnewuspass" value="Send Username/Password" /> </form>
<rdar://problem/6213934>
Thanks for the report, but this is not a security bug. It's possible we should change our behavior to match other browsers here for compatibly. Feel free to re-open if Firefox or IE differ from our behavior here.
Hi Adam, I'm reopening this bug (it is a bug and also a security bug), as Safari is only browser with this wrong behavior: - IE 6, 7 and 8 do not auto fill-in any fields on BACK button - FF 3 and 3.5 don't auto fill-in any hidden fields on BACK button - Opera doesn't do it either. - Even Chrome doesn't do it for hidden fields So Safari is only major one to do this and make forms fail because of this: 1) Hidden fields are not part of user input 2) They are provided by the form, and if modified on the fly by javascript, it's based on values given by server and onsubmit only. 3) They make forms which are tokens-based, with tokens being in hidden fields FAIL to re-submit, killing that great Safari feature on intelligent forms. I hope you will be fixing this bug, as explained in report it is a security bug. Should I publish it and file a NIST report, so that security experts can publicly review it if you wish ? Keeping user provided data with BACK button is a great convenience to user (i hit by error a boomkark writing this bug report, so was glad to be in Safari and be able to hit back button). But doing same for hidden fields is really not needed and buggy. Best Regards, Beat
We should match Firefox here, but this isn't a security issue.
Merge this to Bug#23346, which has more discussion. *** This bug has been marked as a duplicate of bug 23346 ***