web安全漏洞相关

 

1，密码输入框input应该 设置：autocompete="off"

 

2，设置HTTPOnly，禁止客户端修改cookie

文章：Cookie中的HttpOnly详解

 

3，不要展示给用户详细的错误信息；

一下内容复制自：https://www.jb51.net/article/135079.htm

标题：详解Asp.net web.config customErrors 如何设置

===============================================================================

customErrors也经常在开发部署中看到<customErrors mode="Off" />，设置这样可以在页面上看到详细的错误信息。但也为黑客提供了攻击的线索。

customErrors

该节点有三种可选的设置项

1. On：服务器开发的最安全选项，因为它总是隐藏错误提示信息。
2. RemoteOnly：向大多数用户展示一般的错误信息，但向拥有服务器访问权限的用户展示完整的错误提示信息。换句话说，仅向远程客户端端显示自定义错误，并向本地主机显示 ASP.NET 错误。默认值。
3. Off：最容易受到攻击的选项，它向访问网站的每个用户展示详细的错误提示消息。

详细的错误信息可能会暴露应用程序的内部结构，比如如果写的sql语句中报错，可能会暴露数据表，以及sql语句，这是非常不安全的。在Off设置下的网站，黑客会不断的尝试，传递不同的参数，使你的网站出错，然后暴露你的应用程序的内部结构。

mode=Off

<system.web>
  <authentication mode="None" />
  <compilation debug="true" targetFramework="4.5" />
  <httpRuntime targetFramework="4.5" />
  <customErrors mode="Off" defaultRedirect="error">
  </customErrors>
 </system.web>

 

在TestAction中直接抛出一个异常，那么我们可以看到与下面类似的黄页

在黄页上面可以看到，页面对应逻辑的堆栈信息，进而暴露项目结构信息。非常的不安全。

那么如果是mode=Off，并且在事件Application_Error中记录并清除错误，会看到什么结果？

protected void Application_Error(object sender, EventArgs e)
    {
      var context = HttpContext.Current;
      if (context != null)
      {
 
        Exception objErr = context.Server.GetLastError();
        if (objErr != null)
        {
          string err = "Error Caught in Application_Error event/n" + "Error in:"
+ Request.Url.ToString() + "/nError Message:" + objErr.Message.ToString() +
       "/nStack Trace:" + objErr.StackTrace.ToString();
        、、、、、日志逻辑
          Server.ClearError(); 
        }
      }
    }

<customErrors mode="Off" defaultRedirect="Error">   
</customErrors>

defaultRedirect 指定发生错误时浏览器指向的默认 URL。如果没有指定 defaultRedirect，则会显示一般性错误。URL 既可以是绝对的（例如 http://www.***.com/ErrorPage.htm），也可以是相对的。相对 URL（如 /ErrorPage.htm）是相对于指定 defaultRedirect 的 Web.config 文件而言的，而不是针对产生错误的网页。以波形符 (~) 开头的 URL（如 ~/ErrorPage.htm）表示所指定的 URL 是相对于应用程序根路径而言的。

通过上面的操作，如果设置Off，并且在Application_Error事件中捕获异常，并 Server.ClearError()，那么如果报错，在前端页面就会看到空白的页面。

 

通过这个也可以说明，如果应用程序出错，先触发的Application_Error事件，ClearError之后，那么在页面上就看不到结果了。

mode=On

在设置On模式情况下，如果应用程序发生错误，会跳转到自定义的错误页，这里使用了defaultRedirect属性，并没有配置 <error statusCode="500" redirect="error"/>

mode=RemoteOnly

通过字面意思，仅仅远程，仅仅远程什么呢？可以看下例子。目前所在编码环境，通过vs调试状态，相对远程要访问的用户，可以将本机当做服务器。那么这就是本地，远程访问的浏览器就是Remote。

可以看到，在服务器端，访问仍然能看到黄页，也就是上面所说的ASP.NET错误。那么我们将站点部署在服务器，然后在本地访问会出现什么情况呢？

 

通过客户端访问服务器的url，则会跳转到默认的自定义错误页面。那么在服务器端又是什么情况呢？

 

说明： 仅向远程客户端端显示自定义错误，并向本地主机显示 ASP.NET 错误

 总结

所以，不要在生产环境中将customErrors关闭。 推荐开启RemoteOnly或者On并定义自定义的错误页面。

 

=========================================================

 

4，

A.确保web应用程序验证所有表单、头、cookie字段、隐藏字段和参数
B.确保无论何时将HTTP请求发送到HTTP后端，都要对用户提供的输入进行编码
C.从客户端角度来看，在将用户提供的内容放置在链接中时使用URL编码

 

5,cookie要设置过期时间，不要让cookie过期时间变成永久；

 

6，文章：低危漏洞- X-Frame-Options Header未配置

===========================================================

详细内容请点击查看原文；

配置 IIS

配置 IIS 发送 X-Frame-Options 响应头，添加下面的配置到 Web.config 文件中:

<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>

X-Frame-Options 响应头 
X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>, </iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。

使用 X-Frame-Options 
X-Frame-Options 有三个值:

DENY 
表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。 
SAMEORIGIN 
表示该页面可以在相同域名页面的 frame 中展示。 
ALLOW-FROM uri 
表示该页面可以在指定来源的 frame 中展示。 
换一句话说，如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为 SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套。

 

==============================================================

7，跨站脚本保护 Missing Cross-Frame Scripting Protection
跨框架脚本漏洞允许脆弱的应用程序页面被包含在恶意网站的iframe中。当受害者被诱骗通过浏览器访问恶意网页时，就会发生这种情况
“点击劫持”

欺骗用户在不知情的情况下在HTML iframe标记内的脆弱站点上进行交互。

如果成功利用跨帧脚本，攻击者可以进行钓鱼、帧嗅探、社会工程或跨站点请求伪造攻击

 

应用程序的HTTP响应字段中没有设置X-Frame-Options标头在应用程序的HTML主体内容中没有找到框架破坏脚本(参见下面的建议)

下面是一些关于如何保护应用程序不受点击劫持的方法：

客户端保护:框架破坏
这种技术是为了防止站点在试图装入iframe时无法正常工作。
将ID应用于样式元素

<style id="antiClickjack">body{display:none !important;}</style>

然后，在脚本中立即根据其ID删除样式

<script type="text/javascript">
　　if (self === top) {
　　　　var antiClickjack = document.getElementById("antiClickjack");
　　　　antiClickjack.parentNode.removeChild(antiClickjack);
　　} else {
　　　　top.location = self.location;
　　}
</script>

在这种方法中，所有内容都在文档头中，并且可能需要API中的一个方法。

X-Frame-Options响应标头指示浏览器是否应该允许站点呈现在框架或对象中。这确保避免点击劫持攻击

 

X Frame Options permitted values are –
X-Frame-Options: Deny
Page cannot be displayed in a frame
X-Frame-Options: Sameorigin
Page can be display in a frame on the same origin
X-Frame-Options: Allow-From “https://url.com”
Page can be displayed in a frame on a specified URL
This can be configure according on what type of server use –

Apache
To configure Apache to send the X-Frame-Options header for all pages, add this to your site's configuration

 

Header always append X-Frame-Options DENY

Ngix
To configure nginx to send the X-Frame-Options header, add this either to your http, server or location configuration

add_header X-Frame-Options DENY;

Microsoft IIS
To configure IIS to send the X-Frame-Options header, add this your site's web.config file

<system.webServer>
...
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="DENY" />
</customHeaders>
</httpProtocol>
...
</system.webServer>

地址：https://www.owasp.org/index.php/Cross_Frame_Scripting

X Frame Options
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

Clickjacking
https://www.owasp.org/index.php/Clickjacking

 

 

8，百度十大应用程序安全风险

注入攻击；

认证中断；

应用程序和api不能正确地保护敏感数据，比如金融、医疗和PII。攻击者可能会窃取或修改这些保护薄弱的数据，从而实施信用卡欺诈、身份盗窃或其他犯罪行为。在没有额外保护的情况下，例如在休息或传输中加密，敏感数据可能会受到损害，在与浏览器交换时需要特别注意。

访问控制中断；

安全配置错误
安全配置错误是最常见的问题。这通常是不安全的默认配置、不完整的或临时配置、开放的云存储、配置错误的HTTP头文件和包含敏感信息的冗长错误消息的结果。不仅要安全地配置所有操作系统、框架、库和应用程序，而且还必须及时地对它们进行补丁和/或升级

 

跨站点脚本编制(XSS)
当应用程序在新的web页面中包含不受信任的数据而没有进行适当的验证或转义，或者使用可以创建HTML或JavaScript的浏览器API使用用户提供的数据更新现有的web页面时，就会出现XSS缺陷。XSS允许攻击者在受害者的浏览器中执行脚本，这些脚本可以劫持用户会话、破坏web站点或将用户重定向到恶意站点

不安全的反序列化
不安全的反序列化通常会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，它们也可以用来执行攻击，包括重放攻击、注入攻击和特权升级攻击。