From: Geoffrey T. <gta...@na...> - 2002-06-12 14:02:06
|
2 thoughts: 1) I'm pretty sure that youre right -- SecurePage doesn't handle POST properly. It needs to encode the posted variables into hidden fields in the login form, but it doesn't. Patches welcome. 2) If you use your browser's BACK button to go back to the login form, then re-post the user name and password, it will always fail to log you in. This is by design. A unique random ID (I think it's called "loginid") is generated in a hidden variable in the login form and also saved in the session, then it is only allowed to be used once after which it is erased from the session. I put this in for security reasons, so somebody couldn't log out, then have some nefarious individual go up to their machine and use the BACK button to go back to the login page, re-POST it, and therefore get logged back in without having to know the user name and password. Maybe step 2 above is unnecessary paranoia -- any thoughts? - Geoff > -----Original Message----- > From: Steve Freitas [mailto:sf...@ih...] > Sent: Wednesday, June 12, 2002 3:17 AM > To: Webware Discuss > Subject: [Webware-discuss] Re: Session glitches with actions under > SecurePage? > > > Just a quick followup. I noticed it did it again, this time when an > exception was thrown inside a try-catch block in Page 2. > > If it matters, the exception was smtplib.SMTPRecipientsRefused. > > So instead of logging in, I hit the Back button, which > brought me back to > Page 1. Then I hit Reload, and it demanded a login. > > So, at the very least, something about exceptions is invalidating my > session, I believe. In fact, I remember increased frequency > of this behavior > when I was writing exception handling for code using the > MySQLdb module. > > Steve > > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Geoffrey T. <gta...@na...> - 2002-06-20 14:22:31
|
Steve Freitas wrote: > >> 1) I'm pretty sure that youre right -- SecurePage doesn't > handle POST > >> properly. It needs to encode the posted variables into > hidden fields in the > >> login form, but it doesn't. Patches welcome. > > Geoff, tell me what you think of this patch. I hope I know > slightly more > than the minimum required to be dangerous. :-) 1) self.request().fields() returns a dictionary. You're iterating using for passedInValue in self.request().fields(): which I am pretty sure doesn't work in Python 2.0 which Webware is still supposed to support. Iterating over the keys of a dictionary implicitly was added later. Better would be to do: for name, value in self.request().fields().items(): which will work, and also saves an additional dictionary lookup for each item. 2) You need to encode the value in case it contains a double-quote character. value.replace('"', '"') should do the trick I think. 3) I believe that the values in the dict can be strings OR lists of strings. So you need to check if the value is a list, and if so, loop over the items in the list and output a separate hidden field for each item in the list. This will happen with a URL like /foo/bar?field=foo&field=bar in which case you'll have a fields dict like {'field': ['foo', 'bar']} I think. - Geoff |
From: Ian B. <ia...@co...> - 2002-06-20 15:35:10
|
On Thu, 2002-06-20 at 09:22, Geoffrey Talvola wrote: > 2) You need to encode the value in case it contains a double-quote > character. value.replace('"', '"') should do the trick I think. You should use WebUtils.Funcs.htmlEncode for this (since <> should also be replaced) Ian |
From: Steve F. <st...@ne...> - 2002-06-20 18:54:25
Attachments:
LoginPage.patch
|
> Better would be to do: >=20 > =09for name, value in self.request().fields().items(): >=20 > which will work, and also saves an additional dictionary lookup for eac= h > item. >=20 > 2) You need to encode the value in case it contains a double-quote > character. value.replace('"', '"') should do the trick I think. Check. Let me know what you think of the attached patch. > 3) I believe that the values in the dict can be strings OR lists of str= ings. > So you need to check if the value is a list, and if so, loop over the i= tems > in the list and output a separate hidden field for each item in the lis= t. > This will happen with a URL like /foo/bar?field=3Dfoo&field=3Dbar in wh= ich case > you'll have a fields dict like {'field': ['foo', 'bar']} I think. I haven't tried explicitly checking for type list, but I've tried this wi= th=20 multiple values, and it works fine. Do you still suggest handling type li= st? Steve |
From: Geoffrey T. <gta...@na...> - 2002-06-21 15:55:58
|
In your testing, did you try a URL with a query string with the same field repeated, like /foo/bar?field=foo&field=bar ? If so, what was the resulting set of hidden fields? - Geoff > -----Original Message----- > From: Steve Freitas [mailto:st...@ne...] > Sent: Thursday, June 20, 2002 2:54 PM > To: Geoffrey Talvola; Webware Discuss > Subject: Re: [Webware-discuss] Re: Session glitches with actions under > SecurePage? > > > > Better would be to do: > > > > for name, value in self.request().fields().items(): > > > > which will work, and also saves an additional dictionary > lookup for each > > item. > > > > 2) You need to encode the value in case it contains a double-quote > > character. value.replace('"', '"') should do the > trick I think. > > Check. Let me know what you think of the attached patch. > > > 3) I believe that the values in the dict can be strings OR > lists of strings. > > So you need to check if the value is a list, and if so, > loop over the items > > in the list and output a separate hidden field for each > item in the list. > > This will happen with a URL like > /foo/bar?field=foo&field=bar in which case > > you'll have a fields dict like {'field': ['foo', 'bar']} I think. > > I haven't tried explicitly checking for type list, but I've > tried this with > multiple values, and it works fine. Do you still suggest > handling type list? > > Steve > |
From: Steve F. <st...@ne...> - 2002-06-27 10:41:24
|
> In your testing, did you try a URL with a query string with the same field > repeated, like /foo/bar?field=foo&field=bar ? > > If so, what was the resulting set of hidden fields? The resulting set of tracebacks motivated me to produce this patch. :-) I'm grateful for your help. Continue to feel free to point out anything bad (bugs) or undesirable (non-Pythonic or Webwaric style, suboptimal variable names, etc.). Steve > > - Geoff > >> -----Original Message----- >> From: Steve Freitas [mailto:st...@ne...] >> Sent: Thursday, June 20, 2002 2:54 PM >> To: Geoffrey Talvola; Webware Discuss >> Subject: Re: [Webware-discuss] Re: Session glitches with actions under >> SecurePage? >> >> >>> Better would be to do: >>> >>> for name, value in self.request().fields().items(): >>> >>> which will work, and also saves an additional dictionary >> lookup for each >>> item. >>> >>> 2) You need to encode the value in case it contains a double-quote >>> character. value.replace('"', '"') should do the >> trick I think. >> >> Check. Let me know what you think of the attached patch. >> >>> 3) I believe that the values in the dict can be strings OR >> lists of strings. >>> So you need to check if the value is a list, and if so, >> loop over the items >>> in the list and output a separate hidden field for each >> item in the list. >>> This will happen with a URL like >> /foo/bar?field=foo&field=bar in which case >>> you'll have a fields dict like {'field': ['foo', 'bar']} I think. >> >> I haven't tried explicitly checking for type list, but I've >> tried this with >> multiple values, and it works fine. Do you still suggest >> handling type list? >> >> Steve >> > |
From: Steve F. <sf...@ih...> - 2002-06-12 15:45:39
|
> 1) I'm pretty sure that youre right -- SecurePage doesn't handle POST > properly. It needs to encode the posted variables into hidden fields in the > login form, but it doesn't. Patches welcome. Okay, that shouldn't be too hard. I'll whip something up. > 2) If you use your browser's BACK button to go back to the login form, then > re-post the user name and password, it will always fail to log you in. This > is by design. Well, I'm not using BACK to go clear back to the login form, just to Page 1, which I'd already logged into. Does your answer still apply here? > Maybe step 2 above is unnecessary paranoia -- any thoughts? "Unnecessary paranoia?" In computer security, there is no such thing. Steve > > - Geoff > >> -----Original Message----- >> From: Steve Freitas [mailto:sf...@ih...] >> Sent: Wednesday, June 12, 2002 3:17 AM >> To: Webware Discuss >> Subject: [Webware-discuss] Re: Session glitches with actions under >> SecurePage? >> >> >> Just a quick followup. I noticed it did it again, this time when an >> exception was thrown inside a try-catch block in Page 2. >> >> If it matters, the exception was smtplib.SMTPRecipientsRefused. >> >> So instead of logging in, I hit the Back button, which >> brought me back to >> Page 1. Then I hit Reload, and it demanded a login. >> >> So, at the very least, something about exceptions is invalidating my >> session, I believe. In fact, I remember increased frequency >> of this behavior >> when I was writing exception handling for code using the >> MySQLdb module. >> >> Steve >> >> >> _______________________________________________________________ >> >> Sponsored by: >> ThinkGeek at http://www.ThinkGeek.com/ >> _______________________________________________ >> Webware-discuss mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webware-discuss >> > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Steve F. <sf...@ih...> - 2002-06-20 08:00:32
|
>> 1) I'm pretty sure that youre right -- SecurePage doesn't handle POST >> properly. It needs to encode the posted variables into hidden fields in the >> login form, but it doesn't. Patches welcome. Geoff, tell me what you think of this patch. I hope I know slightly more than the minimum required to be dangerous. :-) Steve > Okay, that shouldn't be too hard. I'll whip something up. > >> 2) If you use your browser's BACK button to go back to the login form, then >> re-post the user name and password, it will always fail to log you in. This >> is by design. > > Well, I'm not using BACK to go clear back to the login form, just to Page 1, > which I'd already logged into. Does your answer still apply here? > >> Maybe step 2 above is unnecessary paranoia -- any thoughts? > > "Unnecessary paranoia?" In computer security, there is no such thing. > > Steve > >> >> - Geoff >> >>> -----Original Message----- >>> From: Steve Freitas [mailto:sf...@ih...] >>> Sent: Wednesday, June 12, 2002 3:17 AM >>> To: Webware Discuss >>> Subject: [Webware-discuss] Re: Session glitches with actions under >>> SecurePage? >>> >>> >>> Just a quick followup. I noticed it did it again, this time when an >>> exception was thrown inside a try-catch block in Page 2. >>> >>> If it matters, the exception was smtplib.SMTPRecipientsRefused. >>> >>> So instead of logging in, I hit the Back button, which >>> brought me back to >>> Page 1. Then I hit Reload, and it demanded a login. >>> >>> So, at the very least, something about exceptions is invalidating my >>> session, I believe. In fact, I remember increased frequency >>> of this behavior >>> when I was writing exception handling for code using the >>> MySQLdb module. >>> >>> Steve >>> >>> >>> _______________________________________________________________ >>> >>> Sponsored by: >>> ThinkGeek at http://www.ThinkGeek.com/ >>> _______________________________________________ >>> Webware-discuss mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/webware-discuss >>> >> >> _______________________________________________________________ >> >> Sponsored by: >> ThinkGeek at http://www.ThinkGeek.com/ >> _______________________________________________ >> Webware-discuss mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webware-discuss >> > > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |