安全篇 ━━ 整改php和IIS（根据安全等级保护评估、渗透测试报告）_iis content-security-policy

1、HTTP响应标头

响应头的一般设置参考：提高安全性而在HTTP响应头中可以使用的各种响应头字段

* 点击劫持：X-Frame-Options未配置

点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。
HTTP 响应头信息中的X-Frame-Options，可以指示浏览器是否应该加载一个 iframe 中的页面。如果服务器响应头信息中没有X-Frame-Options，则该网站存在ClickJacking攻击风险。网站可以通过设置 X-Frame-Options 阻止站点内的页面被其他页面嵌入从而防止点击劫持。

修改web服务器配置，添加X-Frame-Options响应头。赋值有如下三种：

1. DENY：浏览器拒绝当前页面加载任何Frame页面，不能被嵌入到任何iframe或者frame中。
2. SAMEORIGIN：frame页面的地址只能为同源域名下的页面，页面只能被本站页面嵌入到iframe或者frame中。
3. ALLOW-FROM：origin为允许frame加载的页面地址，只能被嵌入到指定域名的框架中。

• apache可配置http.conf如下：

<IfModule headers_module> 
	Header always append X-Frame-Options "DENY" 
</IfModule> 
1
2
3

• IIS可配置相关网站的Web.config如下：

<system.webServer> 
  ... 
  <httpProtocol> 
    <customHeaders> 
      <add name="X-Frame-Options" value="deny" /> 
    </customHeaders> 
  </httpProtocol>  
  ... 
</system.webServer>
1
2
3
4
5
6
7
8
9

在IIS设置 X-Frame-Options 为 SAMEORIGIN

页面标记：

<meta http-equiv="X-Frame-Options" content="DENY" />
1

注意，有些语法在chrome或firefox中不适用，详细用法参考：
禁止iframe技术：X-Frame-Options frame-ancestors

* 目标Content-Security-Policy响应头缺失

HTTP 响应头Content-Security-Policy允许站点管理者控制用户代理能够为指定的页面加载哪些资源。除了少数例外情况，设置的政策主要涉及指定服务器的源和脚本结束点。
Content-Security-Policy响应头的缺失使得目标URL更易遭受跨站脚本攻击。

在IIS设置Content-Security-Policy值为default-src * data: ‘unsafe-inline’ ‘unsafe-eval’;frame-src ‘self’; style-src ‘self’ ‘unsafe-inline’; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’

页面标记：
在页面头部设置Content-Security-Policy值为default-src * data: ‘unsafe-inline’ ‘unsafe-eval’;frame-src ‘self’; style-src ‘self’ ‘unsafe-inline’; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’

如果不调用外部js或css，那么下面这行代码写在网页上就没什么问题。

<meta http-equiv="Content-Security-Policy" content="default-src * data: frame-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">
1

在页面头部写上可能造成无法读取js或css等外部文件，此时可删去页面上的设置，仅保留服务器上的。
在服务器上如此配置可能造成无法引用外部代码的错误，比如有些页面需要嵌入第三方客服js代码，那么这个配置存在就会导致ie浏览器还能显示，其它内核浏览器都不能正常运行。
服务器上可以删除限制外部的命令，比如只留 default-src * data: 'unsafe-inline' 'unsafe-eval';cdvfile: gap:;frame-src 'self';

页面上如果要引用外部代码，又必须要写这句安全语句，那么也可以根据上面的原则，将meta改为：

<meta http-equiv="Content-Security-Policy" content="default-src * data: 'unsafe-inline' 'unsafe-eval';frame-src 'self';">
1

参考：
内容安全策略Content Security Policy( CSP )
内容安全策略( CSP )

* 目标Referrer-Policy响应头缺失

Web 服务器对于 HTTP 请求的响应头中缺少 Referrer-Policy，这将导致浏览器提供的安全特性失效。
当用户在浏览器上点击一个链接时，会产生一个 HTTP 请求，用于获取新的页面内容，而在该请求的报头中，会包含一个 Referrer，用以指定该请求是从哪个页面跳转页来的，常被用于分析用户来源等信息。> 但是也成为了一个不安全的因素，所以就有了 Referrer-Policy，用于过滤 Referrer 报头内容，其
可选项有： no-referrer no-referrer-when-downgrade origin origin-when-cross-origin same-origin strict-origin strict-origin-when-cross-origin unsafe-url
漏洞危害： Web 服务器对于 HTTP 请求的响应头中缺少 Referrer-Policy，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。

• 修改服务端程序，给 HTTP 响应头加上 Referrer-Policy

1. 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“Referrer-Policy”, “value”)
2. 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“Referrer-Policy: value”)
3. 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “Referrer-Policy”, “value”
4. 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“Referrer-Policy”] = “value”
5. 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“Referrer-Policy”] = “value”；

• 修改负载均衡或反向代理服务器，给 HTTP 响应头加上 Referrer-Policy

1. 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header Referrer-Policy value;
2. 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add Referrer-Policy “value”。

在IIS设置Referrer-Policy为value

注意，这里的value的值由自己选择
详细用法参考：http请求的时候Referrer-Policy是什么鬼？

* 目标Strict-Transport-Security响应头缺失

Web 服务器对于 HTTP 请求的响应头中缺少 Strict-Transport-Security，这将导致浏览器提供的安全特性失效。 当 Web 服务器的 HTTP 头中包含 Strict-Transport-Security 头时，浏览器将持续使用 HTTPS 来访问 Web 站点，可以用来对抗协议降级攻击和 Cookie 劫持攻击。
其可选的值有： max-age=SECONDS，表示本次命令在未来的生效时间 includeSubDomains，可以用来指定是否对子域名生效
漏洞危害： Web 服务器对于 HTTP 请求的响应头中缺少 Strict-Transport-Security，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。

• 修改服务端程序，给 HTTP 响应头加上 Strict-Transport-Security

1. 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“Strict-Transport-Security”, “value”)
2. 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“Strict-Transport-Security: value”)
3. 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “Strict-Transport-Security”, “value”
4. 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“Strict-Transport-Security”] = “value”
5. 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“Strict-Transport-Security”] = “value”；

• 修改负载均衡或反向代理服务器，给 HTTP 响应头加上 Strict-Transport-Security

1. 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header Strict-Transport-Security value;
2. 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add Strict-Transport-Security “value”。

在IIS设置Strict-Transport-Security为value

注意这里value值：Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]
例如：Strict-Transport-Security: max-age=31536000; includeSubDomains
具体用法参考：IIS - 开启HSTS让浏览器默认以HTTPS访问（强制跳转HTTPS）

* 目标X-Content-Type-Options响应头缺失

X-Content-Type-Options HTTP 消息头相当于一个提示标志，被服务器用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型 的设定，而不能对其进行修改。这就禁用了客户端的 MIME 类型嗅探行为，换句话说，也就是意味着网站管理员确定自己的设置没有问题。

在IIS设置X-Content-Type-Options为nosniff

页面标记：
在代码部分设置X-Content-Type-Options为nosniff

<meta http-equiv="X-Content-Type-Options" content="nosniff" />
1

* 目标X-Download-Options响应头缺失

Web 服务器对于 HTTP 请求的响应头中缺少 X-Download-Options，这将导致浏览器提供的安全特性失效。
漏洞危害: Web 服务器对于 HTTP 请求的响应头中缺少 X-Download-Options，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。

• 修改服务端程序，给 HTTP 响应头加上 X-Download-Options

1. 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“X-Download-Options”, “value”)
2. 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“X-Download-Options: value”)
3. 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “X-Download-Options”, “value”
4. 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“X-Download-Options”] = “value”
5. 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“X-Download-Options”] = “value”；

• 修改负载均衡或反向代理服务器，给 HTTP 响应头加上 X-Download-Options

1. 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header X-Download-Options value;
2. 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add X-Download-Options “value”。

在IIS设置X-Download-Options为value

注意value值目前我只查到noopen，如果有人可以提供别的值请留言，谢谢
详细内容参考：
X-Download-Options
HTTP Security Headers and How They Work中X-Download-Options HTTP Header部分

* 目标X-Permitted-Cross-Domain-Policies响应头缺失

Web 服务器对于 HTTP 请求的响应头中缺少 X-Permitted-Cross-Domain-Policies，这将导致浏览器提供的安全特性失效。 当一些在线的 Web Flash 需要加载其他域的内容时，很多 Web 会通过设置一个 crossdomain.xml 文件的方式来控制其跨域方式。很有可能有些开发者并没有修改 crossdomain.xml 文件的权限，但是又有和跨域的 Flash 共享数据的需求，这时候可以通过设置 X-Permitted-Cross-Domain-Policies 头的方式来替代 crossdomain.xml 文件，
可选值有： none master-only by-content-type by-ftp-filename all
漏洞危害： Web 服务器对于 HTTP 请求的响应头中缺少 X-Permitted-Cross-Domain-Policies，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。

• 修改服务端程序，给 HTTP 响应头加上 X-Permitted-Cross-Domain-Policies

1. 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“X-Permitted-Cross-Domain-Policies”, “value”)
2. 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“X-Permitted-Cross-Domain-Policies: value”)
3. 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “X-Permitted-Cross-Domain-Policies”, “value”
4. 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“X-Permitted-Cross-Domain-Policies”] = “value”
5. 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“X-Permitted-Cross-Domain-Policies”] = “value”；

• 修改负载均衡或反向代理服务器，给 HTTP 响应头加上 X-Permitted-Cross-Domain-Policies

1. 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header X-Permitted-Cross-Domain-Policies value;
2. 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add X-Permitted-Cross-Domain-Policies “value”。

在IIS设置X-Permitted-Cross-Domain-Policies为value

* 目标X-XSS-Protection响应头缺失

HTTP X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面。
X-XSS-Protection响应头的缺失使得目标URL更易遭受跨站脚本攻击。

将您的服务器配置为在所有传出请求上发送值为“1”（例如已启用）的“X-XSS-Protection”头。

1. 对于 Apache，请参阅： http://httpd.apache.org/docs/2.2/mod/mod_headers.html
2. 对于 IIS，请参阅： https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx
3. 对于 nginx，请参阅： http://nginx.org/en/docs/http/ngx_http_headers_module.html

在IIS设置X-XSS-Protection为1

在php代码部分设置X-XSS-Protection为1;mode=block

header("X-XSS-Protection:1");
1

页面标记：

<meta http-equiv="X-XSS-Protection" content="1;mode=block" />
1

2、 目标URL存在http host头攻击漏洞

信任未经验证的http头易受Host头攻击，攻击类型涵盖以下方式：URL跳转钓鱼、客户端反显类攻击、密码钓鱼重置、日志转储命令注入、网络缓存投毒等。

在代码部分注释_SERVER[“HTTP_HOST”]方法，仅留_SERVER["SERVER_NAME”]

去掉后会出现一个问题：如果原网址是zzz.com:88，防火墙指向到1.1.1.1:443服务器，那么得到的端口号将是443，而不是88，这样很可能在某些应用中出错。

在服务器设置主机头为完整域名：

网站绑定 - 编辑 - 主机名
设定明确的域名

1. 一般来说，修复主机头攻击漏洞只需遵循一个原则：不要信任主机头。但是在某些情况下，这说起来容易做起来难（尤其是涉及遗留代码的情况）。
2. 如果必须使用主机头作为识别Web服务器位置的机制，强烈建议维护一个host白名单，难度较大。
3. 配置web程序使用server_name而不是host头。

3、 会话cookie中缺少HttpOnly属性

会话cookie中缺少HttpOnly属性会导致攻击者可以通过程序(JS脚本、Applet等)获取到用户的cookie信息，造成用户cookie信息泄露，增加攻击者的跨站脚本攻击威胁。
HttpOnly是微软对cookie做的扩展，该值指定cookie是否可通过客户端脚本访问。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie属性HttpOnly。
如果在Cookie中没有设置HttpOnly属性为true，可能导致Cookie被窃取。窃取的Cookie可以包含标识站点用户的敏感信息，如ASP.NET会话ID或Forms身份验证票证，攻击者可以重播窃取的Cookie，以便伪装成用户或获取敏感信息，进行跨站脚本攻击等。
如果在Cookie中设置HttpOnly属性为true，兼容浏览器接收到HttpOnly cookie，那么客户端通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这将有助于缓解跨站点脚本威胁。

向所有会话cookie中添加“HttpOnly”属性。

//Java示例： 
HttpServletResponse response2 = (HttpServletResponse)response; 
response2.setHeader( "Set-Cookie", "name=value; HttpOnly");  
 
//C#示例： 
HttpCookie myCookie = new HttpCookie("myCookie");    
myCookie.HttpOnly = true;   
Response.AppendCookie(myCookie); 
 
//VB.NET示例： 
Dim myCookie As HttpCookie = new HttpCookie("myCookie")   
myCookie.HttpOnly = True   
Response.AppendCookie(myCookie)
1
2
3
4
5
6
7
8
9
10
11
12
13

在php代码部分开启HttpOnly，开启后可能发生无法获得session的情况，需清空缓存和临时文件，重启后再试。

ini_set("session.cookie_httponly", 1);  //session必须使用httponly
session_set_cookie_params(0,NULL,NULL,NULL,TRUE); //cookie必须使用httponly
1
2

在IIS开启httpOnlyCookies为True

向所有会话cookie中添加“HttpOnly”属性。

//Java示例： 
HttpServletResponse response2 = (HttpServletResponse)response; 
response2.setHeader( "Set-Cookie", "name=value; HttpOnly");  
 
//C#示例： 
HttpCookie myCookie = new HttpCookie("myCookie");    
myCookie.HttpOnly = true;   
Response.AppendCookie(myCookie); 
 
//VB.NET示例： 
Dim myCookie As HttpCookie = new HttpCookie("myCookie")   
myCookie.HttpOnly = True   
Response.AppendCookie(myCookie)
1
2
3
4
5
6
7
8
9
10
11
12
13

4、 目标服务器启用了OPTIONS方法

OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。OPTIONS方法可能会暴露一些敏感信息，这些信息将帮助攻击者准备更进一步的攻击。

通过调用OPTIONS方法,可以确定每个目录上允许哪些HTTP方法，可能会引起安全问题。

建议禁用web服务器上的options方法。

在IIS设置请求筛选OPTIONS为False

5、ssl1.0等出现问题，不如屏蔽

参考这篇，下载个软件直接改了ssl
https://blog.csdn.net/snans/article/details/102401057

6、IIS短文件名泄露漏洞

利用通配符猜解文件名，返回为400。

1. 关闭NTFS 8.3文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。
2. 如果是虚拟主机空间用户,可采用以下修复方案：
   1）修改注册列表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1（原值可能为2，此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除）。
   2）如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 — Web 服务扩展 - ASP.NET 选择禁止此功能。
   3）升级net framework 至4.0以上版本。
3. 将web文件夹的内容拷贝到另一个位置，比如D:\www到D:\www.back，然后删除原文件夹D:\www，再重命名D:\www.back到D:\www。如果不重新复制，已经存在的短文件名则是不会消失的。 对于虚拟主机空间用户，如果还不能彻底修复该问题，可以联系提供商协助修改。

7、密码破解

1. 对涉及用户信息的API访问进行频次限制，例如设定单账号登录失败锁定的阈值。
2. 限制单个IP的尝试次数，要考虑同一局域网下登录人数，可能账号不同，但IP一致。
3. 登录操作设定有效的验证码机制，例如（短信、图形等）验证码功能。
4. 登陆失败的返回信息一致，不要显示诸如“密码错误”、“账号不存在之类”等提示，此逻辑缺陷容易被利用进行用户名枚举。
5. 加强账户密码复杂度，且定期强制更新。
6. 设定用户sessionid存续时间，保证账号在一定时间内保持在线或自动退出。

攻击者如果通过构造社会工程学字典+分布式暴力破解节点，可大大增加暴力破解成功的可能性。可能导致后台被恶意控制、用户数据泄露。

8、暴露server和X-Powered-By

参考修改：
https://www.cnblogs.com/laijinquan/p/11182890.html
https://help.aliyun.com/knowledge_detail/155468.html

1. 修改 php.ini 文件。添加或修改 expose_php = Off
2. 修改 iis 的 HTTP响应标头 删除有关的内容，或者增加无关的内容进行迷惑
   
3. 安装URLRewrite组件
   下载地址：https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads，注意要在additional位置下载windows版本。
   

进入组件

添加规则 > 出站规则：空白规则 > 名称：REMOVE_RESPONSE_SERVER > 匹配范围：服务器变量 > 变量名称：RESPONSE_SERVER > 模式：.*

值 可以留白也可以随便写一个，比如nginx

注意：规则名是REMOVE_RESPONSE_SERVER，变量名是RESPONSE_SERVER，不要搞错

或者直接在web.config下加入如下规则

<system.webServer>
	<rewrite>
		<outboundRules>
			<rule name="REMOVE_RESPONSE_SERVER">
				<match serverVariable="RESPONSE_SERVER" pattern=".*" />
				<action type="Rewrite" />
			</rule>
		</outboundRules>
	</rewrite>
</system.webServer>
1
2
3
4
5
6
7
8
9
10

9.文件类型错误解析漏洞

攻击者只需要上传一张含有后门代码的图片即可绕过上传过滤，直接利用该漏洞执行图片后就能拿到网站权限。示例如下：

原因：
当访问www.xx.com/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置“phpinfo.jpg/1.php”，然后构造成SCRIPT_FILENAME(绝对路径)传递给PHP CGI,如果开启了cgi.fix_pathinfo=1选项（这个默认值就是1，所以没有设置过就是开启），那么就会触发在PHP中的如下逻辑：
PHP会认为SCRIPT_FILENAME(绝对路径)是phpinfo.jpg，而1.php是PATH_INFO，所以就会phpinfo.jpg作为PHP文件来解析了。也是一个逻辑问题，所以说我们只需要在正常的.jpg后面加/.php就可以成功的绕过解析。

修改cgi.fix_pathinfo = 0，可能导致部分php框架无法正常使用。

10、HTTP动词篡改的认证旁路

在IIS设置允许谓词为POST,GET

11、HTTP.sys整数溢出，任意代码执行漏洞

CVE_ID:CVE-2015-1635;CNNVD_ID:CNNVD-201504-257;远程代码执行漏洞

参考修改：https://blog.csdn.net/snans/article/details/120078573

1. 下载补丁
   官方补丁集：
   《Microsoft Security Bulletin MS15-034 - Critical》
   windows2008的补丁地址：
   《Security Update for Windows Server 2008 R2 x64 Edition (KB3042553)》
   其它补丁地址参考上面的补丁集，比如windows server 2012 r2的话，复制框线地址下载：
   
2. 安装并测试
   安装后用检测工具测试一下，看看返回错误是否变为400即可。
   本例检测工具为postman。
   《Postman 安装及使用入门教程》
   安装完postman后，在headers中添加Params并Send，如下：

Range: bytes=0-18446744073709551615
1

• 响应400：证明不存在HTTP.sys远程代码执行漏洞。
• 响应416：证明存在HTTP.sys远程代码执行漏洞。

因为postman是通过Chrome执行的，所以如果你的Chrome使用了代理，可能会出现407错误，具体错误列表参考：
《HTTP请求错误200、300、400、401、402、403、404、405、406、407、412、414、415、500、501、502解析》

更多参考：

安全篇 ━━ 根据安全等级保护评估、渗透测试报告整改mysql数据库及windows服务器
安全篇 ━━ windows2008自建证书、IIS配置https服务器及浏览器报错处理
PHP开发日志 ━━ jsrsasign、jsencrypt、php实现前后端数据的RSA加密和解密
IIS短文件名泄露漏洞修复
文件上传漏洞解析及简单绕过技巧
PHP开发日志 ━━ IIS7安装PHP8.0及多个版本如何同时存在一台服务器
被误解的X-XSS-Protection
漏洞修复： Web服务器限制只允许通过GET/POST请求