web安全方面技术含有的东西较多,这里就来理一理web安全方面所涉及的一些问题。 一、xss与sql攻击
二、csrf
三、请求劫持与HTTPS3.1、请求劫持请求劫持现在主要分为两种,DNS劫持与HTTP劫持: DNS劫持:
http劫持:
请求劫持唯一可行的预防方法就是尽量使用HTTPS协议访问。 3.1、公钥和私钥什么是https,这里不再解释了,简单理解就是通过SSL(Secure Sockets Layer)层来加密http数据来进行安全传输。 那使用HTTPS是怎样进行安全数据传输的? 先看个有意思的问题: A、B两个人分别在两个岛上,并且分别有一个箱子,一把锁,和打开这把锁的钥匙(A的钥匙打不开B手上的锁,B的钥匙也打不开A的锁)。此时A要跟B互通情报,此时需要借助C的船运输,C是一个不可靠的人,如果A直接把情报送给B或把情报放在箱子里给B,都可能会被C偷走;如果A把情报锁在箱子里,B没有打开A锁的钥匙无法获得情报内容。请问有什么办法可以尽可能快的让A和B互通情报。 这就是公钥和私钥的问题了,答案比较简单,也对应了公钥和私钥在https中的应用过程。 公钥(Public Key)与私钥(Private Key)是通过一种算法得到的一个密钥对(即一个公钥和一个私钥),公钥是密钥对中公开的部分,私钥则是非公开的部分。公钥通常用于加密会话密钥、验证数字签名,或加密可以用相应的私钥解密的数据。通过这种算法得到的密钥对能保证在世界范围内是唯一的。使用这个密钥对的时候,如果用其中一个密钥加密一段数据,必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密,如果用私钥加密也必须用公钥解密,否则解密将不会成功。---百度百科 3.2、Https的通信过程整个通信过程如下图,以公钥加密方式为例: 1、客户端发送https请求,告诉服务器发将建立https连接 2、服务器将服务端生成的公钥返回给客户端,如果是第一次请求将告诉客户端需要验证链接 3、客户端接收到请求后'client finished'报文串通过获取到的服务器公钥加密发送给服务器,并将客户端生成的公钥也发送给服务器 4、服务器获取到加密的报文和客户端公钥,先使用服务器私钥解密报文,然后将报文通过客户端的公钥加密返回给客户端。 5、客户端通过私钥解密报文,判断是否为自己开始发送的报文串;如果正确,说明安全连接验证成功,将数据通过服务器公钥加密不断发送给服务器,服务器也不断解密获取报文,并通过客户端公钥加密返回给客户端验证。这样就建立了不断通信的连接。 3.3、Https协议头解析以打开 https://github.com/ 的过程为例,请求通用头部如下
先看下请求头的字段 再截取部分返回头的字段
需要注意的upgrade-insecure-requests https正常升级后chrome浏览器会出现下面的警告 考虑到这个问题,w3c在2015年4月份出了一个 Upgrade Insecure Requests 的草案,他的作用就是让浏览器自动升级请求。在服务器的响应头中加入: header("Content-Security-Policy: upgrade-insecure-requests"); 四、其它浏览器web安全控制http层面上浏览器设置的安全性控制较多,这里列几个典型的来看看: 1. X-XSS-Protection这个header主要是用来防止浏览器中的反射性xss。现在,只有IE,chrome和safari(webkit)支持这个header。 正确的设置:
2.X-Content-Type-Options&ems; 这个header主要用来防止在IE9、chrome和safari中的MIME类型混淆攻击。firefox目前对此还存在争议。通常浏览器可以通过嗅探内容本身的方法来决定它是什么类型,而不是看响应中的content-type值。通过设置 X-Content-Type-Options:如果content-type和期望的类型匹配,则不需要嗅探,只能从外部加载确定类型的资源。举个例子,如果加载了一个样式表,那么资源的MIME类型只能是text/css,对于IE中的脚本资源,以下的内容类型是有效的:
对于chrome,则支持下面的MIME 类型:
nosniff – 这个是唯一正确的设置,必须这样。 3. Strict-Transport-SecurityStrict Transport Security (STS) 是用来配置浏览器和服务器之间安全的通信。它主要是用来防止中间人攻击,因为它强制所有的通信都走TLS。目前IE还不支持 STS头。需要注意的是,在普通的http请求中配置STS是没有作用的,因为攻击者很容易就能更改这些值。为了防止这样的现象发生,很多浏览器内置了一个配置了STS的站点list。 正确的设置 : 注意下面的值必须在https中才有效,如果是在http中配置会没有效果。
判断一个主机是否在你的STS缓存中,chrome可以通过访问chrome://net-internals/#hsts,首先,通过域名请求选项来确认此域名是否在你的STS缓存中。然后,通过https访问这个网站,尝试再次请求返回的STS头,来决定是否添加正确。 4.Content-Security-PolicyCSP是一种由开发者定义的安全性政策性申明,通过CSP所约束的的规责指定可信的内容来源(这里的内容可以指脚本、图片、iframe、fton、style等等可能的远程的资源)。通过CSP协定,让WEB能够加载指定安全域名下的资源文件,保证运行时处于一个安全的运行环境中。 正确配置:
5.X-Frame-Options这个header主要用来配置哪些网站可以通过frame来加载资源。它主要是用来防止UI redressing 补偿样式攻击。IE8和firefox 18以后的版本都开始支持ALLOW-FROM。chrome和safari都不支持ALLOW-FROM,但是WebKit已经在研究这个了。 正确的设置
6.Access-Control-Allow-OriginAccess-Control-Allow-Origin是从Cross Origin Resource Sharing (CORS)中分离出来的。这个header是决定哪些网站可以访问资源,通过定义一个通配符来决定是单一的网站还是所有网站可以访问我们的资源。需要注意的是,如果定义了通配符,那么 Access-Control-Allow-Credentials选项就无效了,而且user-agent的cookies不会在请求里发送。 正确的设置
7.Public-Key-Pins公钥固定(Public Key Pinning)是指一个证书链中必须包含一个白名单中的公钥,也就是说只有被列入白名单的证书签发机构(CA)才能为某个域名*.签发证书,而不是你的浏览器中所存储的任何 CA 都可以为之签发。可以理解为https的证书域名白名单。 Public-Key-Pins (PKP)的目的主要是允许网站经营者提供一个哈希过的公共密钥存储在用户的浏览器缓存里。跟Strict-Transport-Security功能相似的是,它能保护用户免遭中间人攻击。这个header可能包含多层的哈希运算,比如pin-sha256=base64(sha256(SPKI)),具体是先将 X.509 证书下的Subject Public Key Info (SPKI) 做sha256哈希运算,然后再做base64编码。然而,这些规定有可能更改,例如有人指出,在引号中封装哈希是无效的,而且在33版本的chrome中也不会保存pkp的哈希到缓存中。 这个header和 STS的作用很像,因为它规定了最大子域名的数量。此外,pkp还提供了一个Public-Key-Pins-Report-Only 头用来报告异常,但是不会强制阻塞证书信息。当然,这些chrome都是不支持的。 |
|