开发者

Stealing Cookies with no user input?

开发者 https://www.devze.com 2022-12-27 07:38 出处:网络
I\'m creating a static site generator with a dynamic admin backend for one user. The site accepts no user开发者_Python百科 input. Does this mean that I am safe from attackers who are trying to steal m

I'm creating a static site generator with a dynamic admin backend for one user. The site accepts no user开发者_Python百科 input. Does this mean that I am safe from attackers who are trying to steal my admin cookie?

(there is no user input, so XSS and other methods don't work, right?)


If there's no user input (no links to click that have any effects, etc.), how does the admin backend qualify as "dynamic"?

But basically: No, not unless you're using HTTPS. Even if you're not accepting input, the cookie is transmitted in plaintext and so can be captured (by a man-in-the-middle attack, etc.) and used. (I assume you don't want other people using the cookie to see the admin stuff.)

Or did I completely misunderstand the question? ;-)


The following feature is a point of vulnerability. This could be a vector in which could be accessed in a nefarious means using CSRF. Malicious JavaScript maybe introduced by performing a CSRF->Stored XSS attack.

There is an "admin dashboard" where I can edit the contents of existing entries or add in new ones.

The problem being that when you are authenticated to this administrative console a hacker can still access this feature by "riding" on your authenticated session and this is the basis of CSRF. In short, the attacker doesn't need to know your session id because your browser does! By visiting a malicious website an attacker can force your browser into sending an http request to your administrative console. In order to pull off this attack the attacker must know the server, the path to the script, and all of the POST/GET parameters, but he doesn't need your password or cookie. If this is an in-house administrative console that this is an unlikely attack vector. But its easy to defend against. The easiest method would be to check the http referer of an http request that is making this "content modification", Motorola does this for many of their network appliances. A more common approach is to use a "csrf token".

CSRF is still a problem if you are using basic-auth via an .htaccess file or a cookie based auth. No matter what you need to prevent malicious forged requests and protect against sniffing by using HTTPS. This is gone into greater detail in the OWASP Top 10, make sure to read "A3: Broken Authentication and Session Management".

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号