sessionid防xss（sessionid被盗）

Session 和 JWT 比较

HTTP是无状态的。所有请求都是无状态的。但是，在某些情况下，我们希望记住我们的状态。例如，在一家在线商店中，当我们将香蕉放入购物车后，我们不希望我们的香蕉在转到另一页上购买苹果时消失。IE。我们希望在浏览网上商店时记住我们的购买状态！

为了克服HTTP请求的无状态本质，我们可以使用session或token。

基于认证的session，服务器将在用户登录之后创建session，然后sessionID存储在用户的浏览器的cookie。当用户保持登录状态时，Cookie将与每个后续请求一起发送。然后，服务器可以将Cookie中存储的sessionID与内存中存储的session信息进行比较，以验证用户的身份并发送具有相应状态的响应！

基于session的身份验证流程

许多Web应用程序使用 *** ON Web token（JWT）代替用于身份验证的session。在基于token的应用程序中，服务器使用机密创建JWT，并将JWT发送到客户端。客户端存储JWT（通常在本地存储中），并在每个请求的标头中都包含JWT。然后，服务器将使用来自客户端的每个请求来验证JWT并发送响应。

这里更大的区别是用户状态没有存储在服务器上，而是状态存储在客户端的token内。大多数现代Web应用程序都使用JWT进行身份验证，因为他的可扩展性和移动设备身份验证。

jsonwebtoken 库可用于在服务器上创建JWTtoken。用户登录后，客户端会将JWTtoken传递回header.authorization.bearer属性。

中间件 [express-jwt](), 可用于通过比较秘密来验证JWTtoken。

基于session的身份验证： 因为session存储在服务器的内存中，所以当大量用户一次使用系统时，扩展就成为一个问题。

基于token的身份验证： 扩展没有问题，因为token存储在客户端。

基于session的身份验证： Cookie通常在单个域或子域上工作，并且如果它们跨域工作，则 通常会被浏览器禁用 （第三方Cookie）。当从不同的域向移动设备和Web设备提供API时，就会出现问题。

基于token的身份验证： cookie没有问题，因为请求标头中包含JWT。

在现代Web应用程序中，更推荐使用JWT的基于token的身份验证。JWT的一个缺点是与存储在cookie中的sessionID相比，JWT的大小要大得多，因为JWT包含更多的用户信息。必须注意确保JWT中仅包含必要的信息，并且应省略敏感信息以防止XSS安全攻击。

Session vs Token Based Authentication

如何正确防御xss攻击?

1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。

传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。

2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的 *** 就是通过优化Web应用开发来减少漏洞，避免被攻击：

①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。

②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。

③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。

3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型更大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：

①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;

②包含分层防御策略四个规则的用户输入分析模块;

③保存互联网上有关XSS恶意网站信息的XSS信息数据库。

xss漏洞如何防御?

1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。

传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。

2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的 *** 就是通过优化Web应用开发来减少漏洞，避免被攻击：

①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。

②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。

③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。

3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型更大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：

①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;

②包含分层防御策略四个规则的用户输入分析模块;

③保存互联网上有关XSS恶意网站信息的XSS信息数据库。

redis实现session共享怎么避免单点故障

单点登录是要求客户端保存用户登录的票据（ticket）的（简化一点，也可以是会话id）

对于不同子域名下，是可以这么做的。通常cookie中，只保存session的标识（id），或者与sessionId一一对应的key。

在访问重要的资源时（不同子域名下），可以要求用户重新输入一次登录密码，或者输入其他用户的安全码。

可以使用 httponly 提高安全属性，但也不能完全防止xss攻击。

如何正确防御xss攻击

传统防御技术

2.1.1基于特征的防御

传统XSS防御多采用特征匹配方式，在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击，采用的模式匹配 *** 一般会需要对“javascript”这个关键字进行检索，一旦发现提交信息中包含“javascript”，就认定为XSS攻击。

2.1.2 基于代码修改的防御

和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种 *** 就是从Web应用开发的角度来避免：

1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。

2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。

3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag(没有javascript)，去掉任何对远程内容的引用(尤其是样式表和javascript)，使用HTTP only的cookie。

当然，如上 *** 将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。

并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。

扩展资料：

XSS攻击的危害包括

1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

3、盗窃企业重要的具有商业价值的资料

4、非法转账

5、强制发送电子邮件

6、网站挂马

7、控制受害者机器向其它网站发起攻击

受攻击事件

新浪微博XSS受攻击事件

2011年6月28日晚，新浪微博出现了一次比较大的XSS攻击事件。

大量用户自动发送诸如：

“郭美美事件的一些未注意到的细节”，“建党大业中穿帮地方”，“让女人心动的100句诗歌”，“这是传说中的神仙眷侣啊”等等微博和私信，并自动关注一位名为hellosamy的用户。

事件的经过线索如下：

20:14，开始有大量带V的认证用户中招转发蠕虫

20:30，某网站中的病毒页面无法访问

20:32，新浪微博中hellosamy用户无法访问

21:02，新浪漏洞修补完毕

百度贴吧xss攻击事件

2014年3月9晚，六安吧等几十个贴吧出现点击推广贴会自动转发等。并且吧友所关注的每个关注的贴吧都会转一遍，病毒循环发帖。并且导致吧务人员，和吧友被封禁。

参考资料：

XSS攻击-百度百科