The point of CSRF attack is that you *DONT* have to hijack the session.
By including for example an image on the attacking website with a src reference to the vulnerable website, the browser load the page of vulnerable website, and if you currently have a session, the browser will be tricked into using your current session. That means, if you're logged in, the attacking website can trick your browser into (unknowingly and against your will) requesting any url on the vulnerable website in the context of your current session.
No session hijacking required. Regards, Sebastiaan Ned Collyer wrote:
My point is, if the code path exists, doing some elaborate session hijacking sniffer something something predict blah... can be a pain in the arse and not really a valuable investment. A better thing would be to ask the devs if it is plausible (regardless of how hard it might be in the real world). If the answer to plausibility is yes, then there needs to be a solution. Not a "yeah its plausible try to hack it" approach. If the OP cannot hack the system, but an attacker uses the exact methods he's described here, then that would be pretty embarrassing for all parties. Martijn Dashorst wrote:I can claim anything in thought experiments. That is easy. Making it true is something different. Martijn
smime.p7s
Description: S/MIME Cryptographic Signature
