Properly escaping anything that goes into a raw HTML field would be an important one for preventing cross site scripting.

Record the requestor/client IP address in application state. This can then be used to help against spoofing. Note: If the clients are coming through a proxy, the HTTP headers may only show the proxy server?s IP address.

Hi Everybody, i use the generated SessionId to find out, who is (ab)using my Serverpages. If there is no Data to this Session, the browser wont go anywhere. The Authentification-Screen is the only thing to be shown! Storing ONLY the SessionId in a Cookie limits the vulnerability of a Session. This wont save you against a "hijacked" SessionId but this Session only has a short lifetime which reduces the risky time, where an intruder has access to the System. Recording the used IP feels not that smart because users could have the same IP when they are placed behind the same Gateway and access the Serverpage via the web. (this was mentioned somewhere before, wasnt it?) Furthermore i check the params against special-chars and fieldlengths to prevent SQL-injects (no to forget that SQL-Statements NEVER should embedded in fields in the HTML-code!). Maybe this is helpfull for some of you out there ... best regards -GHAN-

Depending on the type of application, the session id alone may not be enough. A user may start a business application at the start of the day and not exit it until the end of the working day. A spoof from within the company during this time could be very feasible. I doubt the GUID could be guessed (even given a full working day) but, a hacker could probably use a network sniffer and capture the session ID that way. If the gateway/proxy does not pose a problem with the client IP address, then this will help prevent spoofing the session from another machine. Other HTTP headers can be used to further strengthen things. A determined hacker could easily mess with the IP address headers too so, what shall we do to combat this? (other than using HTTPS that is!) Hacker should be jailed, then we wouldn?t need to debate things like this. Oh well.

Hmm ... then we must get a bit more sophisticated and do it, like its done in browsergames. The User has a set of transactioncodes to "click" around with. Stored and generated in the Backend, they will be taken down one after one. After having used all of them, the USER is forced to re-enter his password. This works quiet well although it sounds complicated and annoying : If a hacker is on the session of USER X, he wont get so far depending on, how many transaction codes are left until re-validation. To make this a bit more nifty, we could supply the USER with a brand new SessionID after positiv validation of username and accesscode. Depending on how paranoid we want to get, we could implement an alarmfunction in the backend, when different events happen on a session and shut it down "at will". Let me put the ingredients together: Frontend: - a Cookie containing the Sessionid - USER is forced to re-enter here and there Backend: - a mechanism to count generated transactioncodes down and demand a re-validation of the USER - an alarm or lets call it monitor-function with automatic shutdown for this Session/user/application - a set of userdata (ie. UserAgent, IP, Screenresolution) which are compared heuristicly here and there while transmitting data between Client and Backend. I guess i will implement a sort of this in my own browsergame i'm progressing :) Those scriptkids already tried to nuke my Chatsystem once so i'm a bit alerted of what happens "out there" ... :))) give it a try :) ... i will after having done the core-system of my work here. -GHAN- "... reality used to be a friend of mine!"