保护oauth承载令牌免受javascript应用中的XSS，CSRF等攻击 [英] Securing oauth bearer token against attacks such as XSS, CSRF in javascript apps
问题描述
我不清楚在使用纯JavaScript应用程序时如何保护(或保护)承载令牌.
我知道，当用户向服务器请求令牌时，它的有效期为14天或24小时.但是一旦用户获得了令牌，就没有任何一种可靠的方法来确保它免受XSS或CSRF攻击(我错过了什么吗?).
现在，可以说用户已登录到Web应用程序，并且浏览器具有此令牌，有效期为14天.如果用户正在访问另一个尝试执行XSS(或CSRF)的Web应用程序，则令牌将公开给第三方应用程序，并且此应用程序可以使用此令牌(?)调用我的应用程序.
我已经尝试过在线搜索，但是对于纯js应用程序以及如何保护令牌没有什么具体的(或易于理解的内容).或在js atm中没有一种好的方法.并且您只是希望(祈祷)攻击不会在令牌有效期内(即14天:|)进行?
欢迎任何想法或投入.
谢谢
可能.不用说，但是我们假设使用SSL证书.
因此，这是一个非常简短的摘要.之所以会出现CSRF，是因为对HTTP端点的请求会自动包含cookie(应如此)以及服务器所描述的必需标头，并且不需要用户进行实际操作.他们只是访问带有CSRF向量的网页.
通常，如果不使用先传递给客户端再传递给服务器的唯一秘密"来验证用户确实打算进行呼叫，则CSRF通常被认为是可能的.一般来说，Web浏览器正在形成针对任何类型的应用程序防御CSRF的主要方法.另外，请确保始终执行TLS连接，否则它们可能会成为公用WIFI网络上的MITM(中间人)攻击的受害者，这会迫使协议降级为易受攻击的SSL弱版本POODLE或完全没有.请仔细阅读HSTS，因为它绝对可以加强我提到的所有内容，并且确实有助于防止令牌被盗 HSTS OWASP 和 HSTS信息维基百科
I am a bit unclear about how to secure (or protect) bearer tokens when using pure JavaScript applications.
I know when user request token to the server it can come with a validity of 14 days or 24 hours. but once the user has token there is no neat (assured) way of securing this from XSS or CSRF attacks (am I missing something?).
Now lets say user is logged into the web application and the browser has this token which is valid for 14 days. If the user is accessing another web application which is trying to do XSS (or CSRF) then the token is exposed to the third party application and this application can make calls to the my application using this token (?)
I have tried to search online but nothing concrete (or something which is easy to understand) coming up for pure js apps and how to protect the token. Or there isn't a good way to do it in js atm. and you just hope (and pray) that the attack will not take place within the validity of token (i.e. 14 days :|)?
Any thoughts or inputs are welcome to this.
Thanks
Edit: It prob. goes without saying but we are assuming the use of SSL certificate.
So, a very quick summary. CSRF occurs because a request to a HTTP end point automatically includes cookies (as it should) plus required headers as described by the server and doesn't require a user to physically do something. They simply visit a web page with the CSRF vector on.
CSRF is generally said to be possible if there is no use of a unique "secret" passed firstly to the client and back to the server to verify that the user indeed intended to make the call. Generally speaking, web browsers are shaping the main ways to protect against CSRF for any type of application. CSRF on OWASP
As you've pointed out, you use a bearer token (sent as a HTTP header) - but you are still protected because requests need to originate from the same origin by default. IF the server allows calls from all origins which is returned in the HTTP headers (which tells your user's web browser if it is allowed) then on their heads be it Same origin policy here.
As for XSS, as long as your cookies at the very least have the "HTTP" flag they are invisible to javascript code on any page the user visits anyway. Plus strictly speaking XSS vectors including the theft of cookies for your site would need to be performed on your site generally speaking. Off the top of my head I can't think of anyway to steal them unless a user is physically on your site. If you set the "Secure" flag this is even better as it forces "Server" only too and ensures the cookie will only be sent when a TLS/SSL connection has been established. XSS on OWASP
Here is a screenshot of cookies listed with the Secure and HTTP flags:
As an extra, make sure you always enforce TLS connections as otherwise they could become victim to a MITM (Man in the middle) attack on a public WIFI network that forces a protocol downgrade to a weak version of SSL that is susceptible to POODLE or non at all. Please read up on HSTS as it will most definitely reinforce everything I have mentioned and really help to prevent the token from being stolen HSTS OWASP and HSTS info wikipedia
这篇关于保护oauth承载令牌免受javascript应用中的XSS，CSRF等攻击的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
