session 跨 iframe 共享 session可以跨浏览器吗
转载
网络攻击手段
Cookie & Session
- 网站通过response设置Cookie给浏览器颁发证书,每次访问网站需要提交证书Cookie,网站负责检测证书
- Cookie不能跨域名,不同域名的网站不能相互操作Cookie
- Cookie保存在客户端,不像Session会占用服务器资源
- Session是通过Cookie实现的,创建Session的时候会创建一个内容为SessionId的Cookie
- Session创建的Cookie的maxAge属性一般为–1,表示只在当前浏览器内有效,并且各浏览器窗口间不共享,关闭浏览器就会失效
- 两个浏览器窗口访问服务器时,会生成两个不同的Session
- 但是由浏览器窗口内的链接、脚本等打开的新窗口(也就是说不是双击桌面浏览器图标等打开的窗口)除外。这类子窗口会共享父窗口的Cookie,因此会共享一个Session。
SQL注入
XSS : 跨站脚本攻击
- 著名的SQL注入漏洞一样,利用了Web页面的编写不完善
- 攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码,当其它用户浏览该网站时,这段HTML代码会自动执行,从而达到攻击的目的
- 所有可输入的地方没有对输入数据进行处理的话,都会存在XSS漏洞
- 通过XSS盗取用户Cookie、破坏页面结构、重定向到其它网站等。
- DOM Based XSS
- 用户登录A
- 攻击者向用户发送带有自定义html代码或js脚本的网站A
- 攻击者通过这段代码盗取用户的网站A的cookie
- Stored XSS
- 网站A可以发表文章
- 攻击者发表带有攻击性的脚步的文章,保存到了服务器
- 任何阅读文章的用户的Cookie都回被盗取
- 输入验证:永远不相信用户的输入。需要对用户的输入进行处理,只允许输入合法的值,其它值一概过滤掉。
- Html encode: 对HTML标签进行转换
- 使用HTTP头指定类型: 很多时候可以使用HTTP头指定内容的类型,使得输出的内容避免被作为HTML解析
CSRF[Cross-Site Request Forgery] : 跨站域请求伪造
- 通过盗用浏览器没过期的Cookie来伪造身份
- 盗用你的身份,以你的名义发送恶意请求
- 利用的是网站对用户浏览器的信任
- 用户登录受信任的网站A,产生Cookie
- 用户被骗登录危险网站B,此时没有登出A(平时多登出)
- B在用户不知情的情况下,发送请求访问A,B攻击了A
- 即使关闭浏览器之后,你本地的Cookie不能保证立刻过期
- 检查 HTTP 头部 Refer 信息,只接受来自本域的请求而忽略外部域的请求
- 不能防范来自本域的攻击
- 浏览器插件,非浏览器,比如用后台代码等方法,可以伪造一些 Refer 信息
- 使用一次性令牌
- 一个正确的令牌设计应该是使用 Session 信息做 Hash,用得出的哈希值来做 CSRF 的令牌。
- 使用验证图片
- 用是对于机器人暴力攻击的防止
- 有一些安全性要求比较高的的应用程序结合验证图片和一次性令牌来做双重保护
- 关键操作每次都输入密码
Session Fixation : 会话固定
- 他不是盗用Cookie里的信息,而是制造SessionId让用户创建他自定义的Cookie
- 访问网站A,获得SessionId
- 诱导用户使用此SID访问并登录被攻击网站B:http://B/?SID=xxx
- 攻击者就能使用此SessionId进行操作
- 用户登录后强制实效当前session id,重新生成一个session替换原先的
Security Header integration : HTTP安全响应头
- 现代浏览器提供了一些安全相关的响应头,使用这些响应头一般只需要修改服务器配置即可
Strict-Transport-Security
- HSTS[HTTP Strict Transport Security] : Http严格安全传输
- strict-transport-security: max-age=16070400; includeSubDomains
- 服务器通过hsts头信息告诉浏览器,总是通过HTTPS来访问它,除了第一次访问,所有的http协议都会被转换成https
- 第一次通过http协议会进行302重定向成https,然后加上strict-transport-security头信息
- strict-transport-security会过期,在用户清楚浏览器缓存时会被清除
- https多了一个SSL层,有两个作用
- SSL依靠证书来验证服务器的身份
- SSL会给报文加密,通过证书交换对称密钥
- https的缺点
- 由于需要交换密钥,握手需要6,7个往返,耗时耗电
- ca证书要申请,要钱
X-Content-Type-Options: nosniff
- 浏览器会根据响应头的Content-Type字段来分辨它们的类型
- 例如:"text/html"代表html文档,"image/png"是PNG图片,"text/css"是CSS样式文档。
- 这个响应头可以禁用浏览器的类型猜测行为,让攻击者无法利用类型猜测特性攻击网站
X-XSS-Protection
- 0:禁用XSS保护;
- 1:启用XSS保护;
- 1; mode=block:启用XSS保护,并在检查到XSS攻击时,停止渲染页面
- 保护机制并不完美,但是开启后仍然可以提升攻击难度,没有特别的理由,不要关闭它。
x-frame-options: SAMEORIGIN
- 减少点击劫持,使得页面无法被嵌入到ifream/fream中,无法被别人利用
- 属性设置
- DENY:不允许被任何页面嵌入;
- SAMEORIGIN:不允许被本域以外的页面嵌入;
- ALLOW-FROM uri:不允许被指定的域名以外的页面嵌入
SSL Certificate
概念
- Secure Sockets Layer 安全套接层
文件
- jks 是 java 的 key store 文件格式. java 提供 keytool 工具操作jks.
- 用于存储证书(trust)或者签名(key)
- public key用于给对方加密,相当于给别人一把锁,private key用于解密,相当于钥匙, 这样自己就可以信任对方传输的内容没有被改变过
- private key用于签名,public key用于验证签名,这样对方就可以,对方给了签名,就可以信任内容就是对方给的
- 证书相当于对方的public key,可以用于认证对方的签名,并且可以用于加密,这样我就可以信任对方的身份,对方也可以信任我的内容
- 如果对方有自己的public key,再加上自己的签名,对方也加过密,就是双向认证
- java使用KeyStore获取.jks文件中的证书和key
- 如果没有指定TrustManager,默认使用java到证书列表:$JAVA_HOME/lib/security/cacerts
- 如果指定了TrustManager,那么只会检查网站证书是否在TrustManager到证书列表中
- 指定KeyManager用于?
keystool
- keytool -cacerts -storepass changeit -list
- 查看jvm下所有证书:路径java_home/jre/secure
- keytool -cacerts -storepass changeit -delete -alias test.ipg-online.com
- 删除jvm某个证书
- keytool -cacerts -storepass changeit -noprompt -trustcacerts -importcert -alias ipg-certificate -file WS4700000057._.1.cer
- 导入一个证书到jvm
- keytool -importcert -keystore ipg-certificate.crt.jks -storepass 'Ca6z!7F:Ye' -alias test.ipg-online.com.crt -file test.ipg-online.com.crt
- 导入一个证书到.jks文件
本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。