GCIH · Question #433
Many of your company's customers have been complaining that their web forum accounts have been compromised, so you have been asked to investigate. After creating an account as a normal user and…
The correct answer is A. Apply a timestamp within the SESSIONID variable and digitally sign or hash it to ensure its. The SESSIONID variable, transmitted via the cookie, is a small four-digit number. Consequently, it can be easily brute-forced (for example using a simple script) and hence, to hijack legitimate users' sessions. Alteration of any value by the end-user can be prevented by…
Question
Many of your company's customers have been complaining that their web forum accounts have been compromised, so you have been asked to investigate. After creating an account as a normal user and logging into the application, you attempt to add a new post and you intercept the request that your browser sends to the web server using Webscarab. This intercepted request is displayed below. Which measure would you propose to prevent application-level manipulation of the accounts from the end-user? User-Agent: Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.8.131 Version/11.11 Host: 192.168.56.101 Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, /;q=0.1 Accept-Language: en-US, en;q=0.9 Accept-Encoding: gzip, deflate Cookie: SESSIONID=1232; logged_in=1; user_id=123 Proxy-Connection: Keep-Alive
Options
- AApply a timestamp within the SESSIONID variable and digitally sign or hash it to ensure its
- BUse POST instead of GET requests, to avoid sending parameters in URLs that can be
- CEnforce SSL encryption to prevent sniffing of the users' credentials.
- DUse client-side filtering of user-supplied data to prevent tampered input from reaching the server.
How the community answered
(37 responses)- A62% (23)
- B22% (8)
- C5% (2)
- D11% (4)
Explanation
The SESSIONID variable, transmitted via the cookie, is a small four-digit number. Consequently, it can be easily brute-forced (for example using a simple script) and hence, to hijack legitimate users' sessions. Alteration of any value by the end-user can be prevented by applying a timestamp within the variable and digitally sign or hash it to ensure its integrity (of course, much more digits "at least 16" should also be used to prevent accidental collision). SSL encryption is also definitely needed, but it will protect the data only in transit and not from the end-user at the application level. Client-side filtering at the user level can be easily bypassed (as for example, by using a web application proxy, like Webscarab). Using such proxies, non-persistent cookies can also be manipulated, as well as POST requests.
Topics
Community Discussion
No community discussion yet for this question.