httponly:如果给某个 cookie 设置了 httpOnly 属性，则无法通过 JS 脚本 读取到该 cookie 的信息，但还Application 中手动修改 cookie，所以只是在一定程度上可以防止 XSS 攻击，不是绝对的安全
虽然设置了httponly之后拿不到cookie，但是还是存在xss跨站语句，阻止的仅仅是获取cookie
可以直接拿账号密码，cookie登录.
浏览器未保存读取密码:需要xss产生于登录地址，利用表单劫持
浏览器保存账号面：产生在后台的XSS，例如存储型XSS
手工判断xss跨站漏洞：
第一关：
第二关：
被转义，查看源代码。
存在htmlsecialchars()函数：
把符号转换为实体化标签，xss经常过滤的情况
第二关：
闭合前面的双引号，"><script>alert(1)</script>
第三关：
还是对<>进行了转义，利用表单的鼠标点击属性。
‘onclick=‘alert(1)
第四关：
第五关：
在关键字onclick过滤，on_click
借助a herf属性，自己创建一个javascript代码
"><a href="javascript:alert(1)">
第六关：
继续用第五关的代码，发现herf被过滤，查看源代码。
关键字都被过滤，使用大写替绕过
"><a hRef="javaScript:alert(1)">
第七关：
和upload-labs一样，代码并无循环过滤，因此可以双写绕过
第八关：
大小写，双写均不行，替换为unicode编码
第九关：
这一关不看代码几乎很难完成，代码会检测是否存在http://
第十关：
&t_sort="type="="type="text"onclick="alert(1)"
查看源代码，发现属性为hidden，被隐藏了。
第十一关：
http referer 头，检测来源。
浏览器会检测此JS代码是否来
CSRF跨站请求脚本，检测来源。管理员在登录状态的情况下，登录时触发了一串添加管理员账号的密码，此时则会添加管理员。
检测来源，也就是浏览器的同源策略，看看是否来自同一个域名，不是同一个域名的不接受
token验证会解决这个问题
此关卡在referer头输入&t_sort="type="="type="text"onclick="alert(1)"
第十二关：
检测user-agent aizhan网也存在跨站
后面的关卡也是各种隐藏的属性，基本都是类似的，不在一一记录。