 Semi-bug, slight misdesign? GET requests. [message #14143] |
Thu, 06 November 2003 04:34  |
Xodnizel
Test
Messages: 7
Registered: November 2003
Karma: 0
|
Junior Member |
|
|
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html is a nice read on the difference between what various HTTP methods should do.
I still stand by my belief that POST requests should be used to change the state of something permanent, and not GET requests.
I've made a list of places in the normal forum where such requests are made(many are made in the admin control panel, but...), to counter that argument that there aren't many such places. :b
Buddy list functions, group manager, ignore list functions, "logout", lock/unlock topics, move threads(the actual move thread request is a GET request), some private message functions, subscription functions(including forum notification), and a few others.
I'm also concerned with the "single click" required to confirm a user after receiving the email. People could be easily tricked/confused into clicking the link when someone else made the registration request(and I wonder if any clients would preemptively fetch the link?).
|
|
|
|
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #14169 is a reply to message #14143] |
Thu, 06 November 2003 18:24  |
|
Anonymous
|
|
|
|
I wasn't concerned with security as much as I was about the behavior of browsers or proxies submitting more than one GET request for a resource that alters something permanently.
Regarding security, what I do now is something like this(generalized example):
<a href=" http://somewhere.net/somescript.php?action=lock&thread=4&k={special id}">
Where specialid is the md5sum of the session id, remote ip address, and some other unique things.
Then if the value of "k" read in somescript.php does not equal to the calculated special id, the request is denied.
I do something similar to this with POST requests. I guess it would be vaguely similar to using the verification aspects of URL sessions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #14202 is a reply to message #14143] |
Sat, 08 November 2003 00:17 |
Xodnizel
Test
Messages: 7
Registered: November 2003
Karma: 0
|
Junior Member |
|
|
| Quote: |
Where specialid is the md5sum of the session id, remote ip address, and some other unique things.
|
Or are you referring to something different? I don't think we're understanding each other still... I'll try giving a specific example from fudforum.
In each message, there's a link to "add to buddy list" beside the message body. Normally, in cookie sessions, the link would be something like:
http://dev.starmen.net/talk/index.php?t=buddy_list&add=204&
Now, if I were to post a message that contained:
[img]http://dev.starmen.net/talk/index.php?t=buddy_list&add=204&[/img]
Anyone who then viewed that message would have that user automatically added to his/her buddy list.
However, in my forum, the link would be like:
http://dev.starmen.net/talk/index.php?t=buddy_list&add=204&S=a1542752efcd5727b8516d13885bf643
(I used "S" because I was lazy. It isn't a session ID, or "sysid" per se, and it can't be used to gain direct access to the user's session).
That "S" key is generated by taking the MD5 sum of the real user session id, remote address, and behind-proxy address(similar to your sysid thing). Since the session ID is kept private, in a cookie, it can not be known by a third party, so the "S" key can't be duplicated by a third party. The other data(remote address, etc.) is used to make the "S" key not have such a close relationship to the session ID, though I don't know if this is totally necessary. It would probably be better to hash the session id with a random number, and regenerate that number if a user hasn't done any action for more than 12 hours.
The reason for this obfuscation is to reduce the chances that anyone will do anything successful with the "S" key if it is obtained, through posting a URL through IRC or similar, or server logs(http_referrer).
So, the passed "S" key is compared to the on-the-fly calculated "S" key in buddy_list.php. If they do not match, an error message is displayed, so that [img] "attack" won't work.
The "S" parameter is generally only passed and checked for URLs that do something automatically, without user confirmation. The URL to just read a message would not contain it, for example.
[Updated on: Sat, 08 November 2003 00:18] Report message to a moderator |
|
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #27455 is a reply to message #14178] |
Thu, 08 September 2005 19:17 |
Anonymous
|
|
|
|
| Ilia wrote on Thu, 06 November 2003 19:28 |
Site create by 3rd party trying to fake a GET or even a POST will be rejected by a referrer check. Using cookie sessions will accomplish that very thing as well, since each visit the user will be assigned a different id.
|
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]