初识cookie
http是无状态的请求响应。每次的请求响应之后,连接会立即断开或延时断开(保持一定的连接有效期)。断开后,下一次请求再重新建立。在http连接时,通过cookie进行会话跟踪,第一次响应时设置的Cookie在随后的每次请求中都会发送出去。
Cookie还可以包括登陆认证后的身份信息。
大多数浏览器限制每个域能有50个cookies左右。存储的cookies最大值约为4kb,若超过这个值,浏览器就会删除一些cookie。
删除策略因浏览器而已。有兴趣的朋友可以自己做深入研究。
删除cookie的操作只需要设置过期值为过去的时间即可。cookie无法跨浏览器存在。
cookie的作用
同域内浏览器中发出的任何一个请求都会带上cookie,无论请求什么资源,请求时,cookie会出现在请求头的cookie字段中。
服务端响应头的set-cookie字段可以添加,修改和删除cookie,大多数情况下,客户端通过JS也可以添加,修改和删除cookie。
cookie经常用来存储用户的会话信息。比如,用户登陆认证后的session,之后同域内发出的请求都会带上认证后的会话信息,非常方便。所以攻击者特别喜欢盗取cookie,这相当于盗取了在目标网站上的用户权限。
Secure Cookie机制
Secure Cookie机制指的是设置了secure标志的cookie。Secure Cookie仅在https层面上安全传输,如果是http请求,就不会带上这个cookie。
这样能降低重要的cookie被中间人截获的风险。
不过,也不是说可以万无一失。因为secure cookie对于客户端脚本来说是可读可写的,可读就意味着secure cookie能被盗取,可写意味着能被篡改,所以还是存在一定的风险。
HttpOnly属性
Cookie的HttpOnly属性,指浏览器不要在除HTTP(和 HTTPS)请求之外暴露Cookie。
一个有HttpOnly属性的Cookie,不能通过非HTTP方式来访问,例如通过调用JavaScript(例如,引用document.cookie),因此,不可能通过跨域脚本(一种非常普通的攻击技术)来偷走这种Cookie。Facebook 和 Google 正在广泛地使用HttpOnly属性。
然而,目前的技术手段还是可以通过xss攻击获取httpOnly的cookie。有兴趣的朋友可以延伸阅读该篇:Stealing HttpOnly Cookie via XSS
Same-Site属性
当用户从a.com发起b.com的请求也会携带上Cookie,而从a.com携带过来的Cookie称为第三方Cookie。
为了防止CSRF(Cross-site request forgrey)攻击,可以使用SameSite属性。
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
strict:浏览器在任何跨域请求中都不会携带Cookie,这样可以有效的防御CSRF攻击,但是对于有多个子域名的网站采用主域名存储用户登录信息的场景,每个子域名都需要用户重新登录,造成用户体验非常的差。
lax:相比较strict,它允许从三方网站跳转过来的时候使用Cookie。
更多延伸阅读:Using the Same-Site Cookie Attribute to Prevent CSRF Attacks
本地cookie与内存cookie
本地cookie与内存cookie,区别在于cookie设置的expires字段。
如果没有设置过期时间,就是内存cookie。随着浏览器的关闭而从内存中消失。
如果设置了过期时间是未来的某一个时间点,那这个cookie就会以文本的形式保存在操作系统本地,待过期时间到了才会消失。
很多网站为了提升用户的体验,省去每次用户登陆的麻烦,采用本地cookie的方式,让用户可以在未来的一个月,或者半年,永久等时间段内不需要进行登陆操作。
这也意味着,用户被攻击的风险变大了。攻击者通过xss得到这样的本地cookie后,能够在未来很长一段时间内,甚至是永久控制这目标用户的账号权限。
然而,即使采用内存cookie也存在一定的风险,攻击者可以给内存cookie加一个过期时间,使其变成本地cookie,这样还是无法避免以上的安全问题。说到底,用户账号是否安全与服务器端校验有关,包括重要cookie的唯一性(是否可预测),完整性(是否被篡改),过期等校验。
web性能与cookie
cookie在服务端和浏览器的通信中,主要依靠HTTP的响应头和请求头传输的,所以cookie会占据一定的带宽。
前面提到浏览器会为每一次HTPP请求自动携带上Cookie信息,但是对于同站内的静态资源,服务器并不需要处理其携带的Cookie,这无形中便浪费了带宽。
在最佳实践中,一般都会将静态资源部署到独立的域名上,从而可以避免无效Cookie的影响。
LocalStorage
LocalStorage也是浏览器本地存储数据的一个地方,是html5的特性。目前已经十分普及了。然而,localStorage并不会像cookie那样可以设置数据存活的时间限制。
只要用户不主动删除,localstorage存储的数据就会永久存在。
因此不建议将敏感信息存储在localstorage中,尤其用于身份验证的数据。localStorage没有对xss攻击做任何防御机制,一旦出现xss漏洞,存储在localstorage的数据及其容易被获取到。
来自:imooc编程手记(微信号:imooc--com)
作者:moweiyang0214
随着网络的普及,黑客进行网络攻击的手段越来也多,越来越复杂。前端的HTML、JavaScript、CSS、Flash等技术变成了前端攻击者和开发者的战场,网站安全问题也开始向前端倾斜。
AJAX请求真的不安全么?AJAX请求哪里不安全?怎么样让AJAX请求更安全?本文包含的内容较多,包括AJAX,CORS,XSS,CSRF等内容,要完整的看完并理解需要付出一定的时间。
第三方内容在其沙箱区域内具有强大的能力。如果你担心恶意用户诱使你的网站加载第三方资源,可以通过 CSP 用作防护手段,其可以限制加载图片,脚本和样式的来源。
检查页面隐藏或丢失的内容:检查webserver元数据文件,如:robots.txt, sitemap.xml,.DS_Store, .htaccess,检查搜索功能可能的注入或攻击方式,检查不同agent代理访问网站显示内容的是否一致
要做到无iFrame,我将使用一种类似于之前我讨论过的方法:我将创建一个弹窗,然后在设置计时器后更改弹出窗口的位置。使用这种方法,我仍然可以加载受害者的CSS,但我不再依赖于受害者是否允许iFrame。
我当前的 chrome 版本是 v68,如果是 v66 或更低版本可能提示的警告信息略有不同。印象中只对 CORS 比较熟悉,CORB 是个什么鬼?好奇心迫使我想要了解一下它到底是什么,于是暂时把手头工作放下查了一些资料并花时间汇总了一下,就有了这篇文章
大家都喜欢target=_blank, 因为新页面打开不影响原来的页面。但是这个存在安全问题, 由target=_blank打开的页面, 可以通过window.opener访问原来的窗口。遍可以简单的将网页导航到其他网站, 这就存在很多的安全隐患了, 比如钓鱼,这种问题解决起来也很简单, 在链接中加入rel=noreferrer noopener属性就可以了
Web安全测试检查单。上传功能:绕过文件上传检查功能,上传文件大小和次数限制。注册功能:注册请求是否安全传输,注册时密码复杂度是否后台检验,激活链接测试
HTTP Strict-Transport-Security,简称为HSTS。X-Frame-Options:是否允许一个页面可在<frame>、<iframe>、<object>中展现的标记。X-XSS-Protection作用:防范XSS攻击。
第三方内容在其沙箱中具有很高的影响力。 虽然图像或沙盒iframe有着非常小的沙箱,但脚本和样式的作用范围却影响你的整个页面,甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源,可以使用CSP(内容安全策略)保证安全
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!