| 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 #14157 is a reply to message #14143] |
Thu, 06 November 2003 16:12  |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Well, given the nature of certain browsers, it would be trivial to 'fake' a post request. It'd just require a little bit of JavaScript, which would trigger on <body onLoad="hack();">. This would submit the form result to the forum effectively causing a POST request as the current user.
The solution is to disallow FUDcode and only allow plain text inside messages, signatures & private messages and use cookie session, which expire as soon as the browser is closed.
E-mail confirmation is secure because it validates a random key unique to each user. The only copy of that key is the one send to the user via e-mail. I do not see how you could trick a person into validating a different account.
FUDforum Core Developer
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #14159 is a reply to message #14157] |
Thu, 06 November 2003 16:16 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Eliminating all GET requests would hinder functionality too much. I mean if we want to obsess with security, we'd force every 'change' action to require user to input their password making the forum virtually unusable.
FUDforum Core Developer
|
|
|
|
| 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 #14170 is a reply to message #14169] |
Thu, 06 November 2003 20:00 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
As of 2.6.0 the session (URL or COOKIE) is already validated against IP, Proxy IPs and browser signature. Unless I misunderstood something, I do not see how that would protect against and attack you seem to imply.
FUDforum Core Developer
|
|
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #14178 is a reply to message #14176] |
Fri, 07 November 2003 00:28 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
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.
FUDforum Core Developer
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #14182 is a reply to message #14143] |
Fri, 07 November 2003 01:38 |
Xodnizel
Test
Messages: 7
Registered: November 2003
Karma: 0
|
Junior Member |
|
|
I did not want to disable images within fudcode, and refereer checks are not always reliable, as you have said. Thought not everyone has cookies enable, and my method requires them...
I'm not understanding what you're saying about cookie sessions. Is the session id or some identifier unique to each user being passed with forms or GET requests that alter data?
|
|
|
|
| Re: Semi-bug, slight misdesign? GET requests. [message #14183 is a reply to message #14182] |
Fri, 07 November 2003 02:06 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Well, suppose we agree on this security key. Could you tell me how would it be generated & authenticated in such a way that it would be difficult to fake?
FUDforum Core Developer
|
|
|
|
| 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
]