We're working on a mobile app and are using session tokens for authentication with a back end server. Is it a security risk to pass the session token from the client to the server in the body? This isn't for authentication, but more so just because of something we're trying to accomplish in the application. The tokens are already passed around in the headers so if someone was sniffing our traffic, then having it in the body doesn't seem like any extra risk- or am I missing something?
Add a comment
|
2 Answers
You're right in assuming that there won't be any extra risk sending the token in the body when you're already sending it in the headers. I question why you would need to send the token in two places, but as far as sniffing traffic it won't be any easier for an attacker to read body traffic than header traffic. If you're sending the traffic over HTTP as opposed to HTTPS you're vulnerable to a man in the middle attack either way.
-
Snigging is not the only issue. What about XSS? You can not mark something as HttpOnly if it is in the body, the way you can with a cookie.– AndersOct 22, 2016 at 8:33
My assumption is that your mobile app is html/javascript based... The fact that your client can send the token as part of the POST body implies that either (1) script on the page reads the token from the header and then constructs the POST or (2) the token is already present somewhere on the page (e.g. hidden form field) and is then POSTed. In both cases if you have an XSS vulnerability on the page then an attacker would be able to steal the token.
OWASP advice on session tokens is to use cookies with the HttpOnly attribute to prevent (1). Note that this will mean that your own legitimate client side code won't be able to access the cookie to do the POST. Preventing (2) wouldn't be possible in the case you have an XSS vulnerability that allows script to access the dom element that represents the session token.
