常见21种漏洞编码安全规范及解决方案

常见21种漏洞编码安全规范

  • 1.sql注入
    • 1.1风险描述
    • 1.2漏洞示例
    • 1.3解决方案
  • 2.跨站脚本攻击(XSS)
    • 2.1风险描述
    • 2.2漏洞示例
    • 2.3解决方案
  • 3.任意文件下载
    • 3.1风险描述
    • 3.2漏洞示例
    • 3.3解决方案
  • 4.任意文件上传
    • 4.1风险描述
    • 4.2解决方案
  • 5.越权操作
    • 5.1风险描述
    • 5.2漏洞示例
    • 5.3解决方案
  • 6.URL跳转
    • 6.1风险描述
    • 6.2漏洞示例
    • 6.3解决方案
  • 7.跨站请求伪造(CSRF)
    • 7.1风险描述
    • 7.2漏洞示例
    • 7.3解决方案
  • 8. 不充分帐户封锁
    • 8.1风险描述
    • 8.2解决方案
  • 9. 密码安全
    • 9.1风险描述
    • 9.2漏洞示例
    • 9.3解决方案
  • 10.敏感数据未加密
    • 10.1风险描述
    • 10.2漏洞示例
    • 10.3解决方案
  • 11. 启用了不安全的HTTP方法
    • 11.1风险描述
    • 11.2解决方案
  • 12. 缺少"Content-Security-Policy"头
    • 12.1风险描述
    • 12.2解决方案
  • 13. 缺少 X-XSS-Protection 头
    • 13.1漏洞描述
    • 13.2解决方案
  • 14. 缺少 X-Content-Type-Options 头
    • 14.1风险描述
    • 14.2解决方案
  • 15. 自动填写未对密码字段禁用的 HTML 属性
    • 15.1漏洞描述
    • 15.2解决方案
  • 16.敏感信息泄露及错误处理
    • 16.1风险描述
    • 16.2解决方案
  • 17. 发现数据库错误模式
    • 17.1风险描述
    • 17.2漏洞示例
    • 17.3解决方案
  • 18.Cookie安全
    • 18.1风险描述
    • 18.2解决方法
  • 19. 会话超时设置
    • 19.1漏洞描述
    • 19.2漏洞示例
    • 19.3解决方案
  • 20.日志处理
    • 20.1风险描述
    • 20.2漏洞示例
    • 20.2解决方案
  • 21 HTTP响应头X-Frame-Options
    • 21.1风险描述
    • 21.2解决方案

1.sql注入

1.1风险描述

SQL注入主要发生在应用程序数据库层面上。程序员在设计程序的时候，没有对用户的输入进行校验，含有特殊字符语句会被数据库误认为是正常的SQL指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码等危害。

1.2漏洞示例

在这里插入图片描述

1.3解决方案

1、检查变量数据类型和格式

如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。

比如，我们前面接受username参数例子中，我们的产品设计应该是在用户注册的一开始，就有一个用户名的规则，比如5-20个字符，只能由大小写字母、数字以及一些安全的符号组成，不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过，仍然有很多例外情况并不能应用到这一准则，比如文章发布系统，评论系统等必须要允许用户提交任意字符串的场景，这就需要采用过滤等其他方案了。

2、添加全局过滤器，过滤特殊字符。

Web.xml

Web.xml
<filter ><filter-name>SQLFilter</filter-name>< filter -class>*.SQLFilte</ filter -class >
</filter >  
<filter-mapping><filter-name> SQLFilter </filter-name><url-pattern> /*</url-pattern>   拦截所有请求
</filter-mapping>
在SQLFilter.java类中：
paramValue= paramValue.replaceAll(“>”, “”)
paramValue= paramValue.replaceAll(“%”,“”)

3、绑定变量，使用预编译语句

MySQL的mysql驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法。

实际上，绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构。

2.跨站脚本攻击(XSS)

2.1风险描述

跨站攻击是因为网站程序对用户输入过滤不足，将用户输入的恶意脚本代码正常执行或者提交。攻击者可利用XSS漏洞获取用户cookie值、传播蠕虫、篡改页面或进行钓鱼等攻击。

跨站脚本攻击（XSS），是最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的。

攻击者可以使用户在浏览器中执行其预定义的恶意脚本，其导致的危害可想而知，如劫持用户会话，插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器、繁殖XSS蠕虫，甚至破坏网站、修改路由器配置信息等。

XSS攻击又分：反射型攻击跟持久型攻击。

第一种XSS攻击是反射型攻击，可能通过图片或者flash的动图之类的诱导你点击一个URL链接。在这个URL链接里就嵌入他自己的恶意脚本，你点击URL链接之后，URL指向的是黑客自己的服务器上的一段恶意脚本，然后恶意脚本被返回到你的浏览器里就会运行，就可以控制你的浏览器里的行为了，比如说脚本可以自动让你关注某个用户ID，然后控制你自动发布一个带有病毒的微博等。

另外一种XSS攻击叫持久型攻击，举个例子，比如某个论坛、或者社交网站之类的系统，你可以发布一些帖子，或者是评论，此时黑客就可以在里面写一段恶意脚本，然后把恶意脚本混杂在评论内容里提交到你的网站的数据库里去。后面比如其他用户在社交网站里浏览到了你的这个评论，评论内容会被返回到浏览器里去，此时评论内容是包含恶意js脚本的，马上恶意脚本运行。达到攻击的目的。

2.2漏洞示例

在这里插入图片描述
点击搜索访问接口：
http://…/searchword?word=…
此处参数在前端为EL表达式获取，并且为添加任何过滤，最后直接显示在页面。当输入框输入的参数为： 时，就会直接被浏览器当作脚本执行并弹框：

在这里插入图片描述
还有一种是将参数进行传递并最终存储到数据库当中，因为参数在传递过程中未经过任何有效过滤(或者存在过滤不全，会被绕过)，作为可信资源存入到数据库中并最终被执行。
在这里插入图片描述
在这里插入图片描述

2.3解决方案

  1. 消毒机制，对用户输入的内容进行转义，比如说把&gt;转义为&gt之类的，这样就可以把恶意脚本里的html标签、js代码之类的东西，都给转义掉，让这些恶意脚本失效。

  2. HttpOnly方式，如果你在浏览器里存放cookie的时候，可以设置一个HttpOnly属性，比如说存放用户加密认证信息的cookie，这样的话，在浏览器里运行的js脚本是被禁止访问这些HttpOnly cookie的，他就无法窃取你在浏览器里存储的cookie了。

response.setHeader
("Set-Cookie","cookiename=httponlyTest;Path=/;Domain=domainvalue;HTTPOnly");

3.任意文件下载

3.1风险描述

网站在处理用户下载文件的请求时，允许用户提交任意文件路径，并把服务器上对应的文件直接发送给用户，这将造成任意文件下载威胁。如果服务器根据用户提交的目录地址，就把目录下的文件列表发给用户，会造成目录遍历安全威胁。恶意用户会变换目录或文件地址，下载服务器上的敏感文件、数据库链接配置文件、网站源代码等。

3.2漏洞示例

下载功能url：
http://…/downloadFile.action?jpgPath=/download/&jpgName=test.jpg
后端代码文件路径和文件名都是从前端获取，然后执行下载操作。

3.3解决方案

1、文件下载时进行过滤，过滤掉 “./”、“…/”、“%”等，代码如下：

在这里插入图片描述

2、对下载的文件路径进行严格控制，只允许下载某部分目录下的文件：

在这里插入图片描述

3、对下载文件后缀名做严格控制：
在这里插入图片描述
4、下载文件之前做权限判断，判断用户是否有下载该文件的权限。可建立文件白名单，不属于白名单内，不允许下载。
5、使用ID替换文件夹和文件名，使得整个输入由路径名变为一个表示ID的字符串，这种方法很容易验证它的有效性。

4.任意文件上传

4.1风险描述

应用程序在处理用户上传的文件时，没有判断文件是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到服务器上，直接控制服务器。文件上传漏洞的利用是有限制条件的，首先要能够成功上传木马文件，其次上传的木马文件能够被执行，最后就是上传文件的路径必须可知。

4.2解决方案

  1. 对上传文件的类型进行检测，设置白名单进行过滤。（建议禁止上传jsp、jspx、php、asp、aspx等格式的文件）。
  2. 对上传文件的内容及大小进行检测。

5.越权操作

5.1风险描述

越权漏洞是比较常见的漏洞类型，越权漏洞可以理解为，一个正常的用户A通常只能够对自己的一些信息进行增删改查，但是由于程序员的一时疏忽未对信息进行增删改查的时候没有进行一个判断，判断所需要操作的信息是否属于对应的用户，可以导致用户A可以操作其他人的信息。​

权限攻击可以分为水平权限攻击和垂直权限攻击。

水平权限攻击，也叫作访问控制攻击。Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或者在判断数据所属人时从用户提交的表单参数中获取了userid。导致攻击者可以自行修改userid修改不属于自己的数据。

垂直权限攻击又叫做权限提升攻击。其原理是由于Web应用没有做权限控制，或仅仅在菜单上做了权限控制，导致恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

5.2漏洞示例

1.水平权限攻击

Web应用在修改用户个人信息时，从用户提交的表单中获取userid，执行修改操作：

在这里插入图片描述

后端直接从表单参数列表中获取userid，修改userid对应的用户数据。

在这里插入图片描述

这时攻击者可以随意修改表单的userid：

在这里插入图片描述

修改userid后，提交表单，就可能修改了其他用户的数据。

5.3解决方案

1.在进行增、删、改、查等操作时，需将sessionID和认证的token绑定，存放在服务器的会话里，不要相信任何客户端发来的认证和授权信息，包括消息头、Cookie、隐藏的表单或者URL参数。

例如：从用户的加密认证cookie中获取当前用户id，并且在执行的sql语句中加入当前用户id作为条件语句。由于cookie是加密的，所以攻击者无法修改加密信息。
在这里插入图片描述
代码中通过GetUseridFromCookie方法，从加密的cookie中获取当前用户的id，并加入判断。

  1. 对于垂直权限攻击，只需要在每个页面的加载之前进行权限验证即可。

6.URL跳转

6.1风险描述

应用程序接收到用户提交的URL参数后，没有对参数做"可信任URL"的验证，就向用户浏览器返回跳转到该URL的指令。恶意攻击者可以发送给用户一个链接，但是用户打开后，却来到钓鱼网站页面，将会导致用户被钓鱼攻击，账号被盗，或账号相关财产被盗。

6.2漏洞示例

跳转代码：response.sendRedirect(request.getParameter(“url”));

某应用程序有一个名为"redirect.jsp"的页面，该页面的参数为"url"，攻击者精心构造一个链接将用户重定向到一个恶意网站，执行钓鱼攻击并安装恶意程序。

6.3解决方案

1、输入验证，对跳转的URL进行验证，对于不合法的跳转URL拒绝跳转访问。可通过白名单进行验证。

2、如果在本网站内跳转，则使用相对路径，而不要使用绝对路径，如在URL的参数中使用了绝对路径，建议在代码里剥离URL中域名部分，然后再和网站的域名重新结合成绝对路径，再跳转。

3、如果请求允许跳转的对象只是限制在有限的范围内，可创建一个匹配的规则，通过数字类型的ID来代替跳转到具体的页面。

7.跨站请求伪造(CSRF)

7.1风险描述

CSRF 是一种攻击者迫使被攻击者网页浏览器发送HTTP 请求到攻击者所选择的网站的漏洞。CSRF依靠用户标识，并利用网站对用户标识的信任欺骗用户浏览器发送HTTP请求给目标站点。通过跨站请求伪造漏洞，攻击者能让受害用户修改可以修改的任何数据，或者是执行允许使用的任何功能。

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。

下图简单阐述了CSRF攻击的思想：
在这里插入图片描述
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。

7.2漏洞示例

bob在银行有一笔存款，可以通过请求

http://bank.example/withdraw?account=bob&amount=1000000&for=bob2

把钱转到bob2下。通常情况下，该请求到达网站后，服务器会验证请求是否来自一个合法的session，并且该session的用户Bob已登录。Tom在该银行也有账户，于是他伪造了一个地址

http://bank.example/withdraw?account=bob&amount=1000000&for=tom ，但是如果直接访问，服务器肯定会识别出当前登录用户是mal而不是Bob，不能接受请求。于是通过CSRF攻击方式，将此链接伪造在广告下，诱使Bob自己点这个链接，那么请求就会携带Bob浏览起的cookie一起发送到银行，而Bob同时又登录了银行或者刚刚登录不久session还没有过期，那服务器发现cookie中有Bob的登录信息，就接收了响应，攻击就成功了。

7.3解决方案

  1. 验证Referer：

referer携带请求来源，从示例可以看出，受害者发送非法请求肯定不是在银行的界面，所以在服务器通过验证Referer是不是bank.example开始就可以了，这个方法简单粗暴。

String referer=request.getHeader("Referer");  if((referer!=null) &&(referer.trim().startsWith("bank.example"))){  chain.doFilter(request, response);  }else{  request.getRequestDispatcher("error.jsp").forward(request,response);  }
  1. 在请求参数中添加token验证：

要抵御跨站点请求伪造就要设置一个黑客伪造不了的东西。我们可以在请求参数中加一个随机token，在服务器验证这个token，通过即销毁重设。

  1. 在HTTP头中自定义属性并验证：

这个方法和上面那个类似，也是设置token，只是把token设置为HTTP头中的自定义属性。

8. 不充分帐户封锁

8.1风险描述

当攻击者试图利用不正确的凭证来登录时，当用户输入无效的用户名和无效的密码时，应用程序会分别生成不同的错误消息。通过利用该行为攻击者可以通过反复试验，加暴力破解来发现应用程序的有效用户名、再继续尝试发现相关联的密码。

8.2解决方案

1、登录的时候密码输入次数过多时锁住用户一段时间不能登录，增加锁的功能。

2、加入图形验证码解决暴力攻击。

9. 密码安全

9.1风险描述

密码安全问题主要存在明文密码、弱密码、密码硬编码等问题。此类问题均容易导致密码的泄露。恶意攻击者可直接读取获得明文账号密码，导致其他相关联系统应用口令泄漏，扩大入侵范围。

9.2漏洞示例

在这里插入图片描述

9.3解决方案

1、配置文件中涉及到需要用户验证的密码字段采用加密后保存，禁止明文或使用弱加密算法对密码进行加密。

2、涉及密码的配置，需要把密码设置具备一定的强度，比如大小写数字特殊字等最少3类型8位以上，并且不能包含与用户名一样的字符串。

3、程序代码中涉及到使用密码的地方，密码引用不得直接写入到程序中，需把密码写入相应的配置文件中。

4、对硬编码密码进行模糊化处理，将密码获取途径分散到其他系统或文件各处，增加直接获取密码难度。

10.敏感数据未加密

10.1风险描述

数据加密主要应用于数据存储及数据传输过程中，敏感数据未加密进行存储或传输，容易导致数据泄露，恶意攻击者可嗅探到明文传输的敏感数据，从而窃取相关信息。

10.2漏洞示例

1.密码明文传输

在这里插入图片描述

2.配置文件密码明文存储

在这里插入图片描述

10.3解决方案

  1. 登陆密码建议采用不可逆的加密方式对密码进行加密如MD5。

  2. 禁止明文或使用弱加密算法对密码进行加密，密码设置应具备一定的强度，大小写数字特殊字等最少3类型8位以上，并且不能包含与用户名一样的字符串。

11. 启用了不安全的HTTP方法

11.1风险描述

除标准的GET与POST方法外，HTTP请求还使用其他各种方法。许多这类方法主要用于完成不常见与特殊的任务。如果低权限用户可以访问这些方法，他们就能够以此向应用程序实施有效攻击。以下是一些值得注意的方法：

PUT，向指定的目录上传附加文件；

DELETE，删除指定的资源；

COPY，将指定的资源复制到Destination消息头指定的位置；

MOVE，将指定的资源移动到Destination消息头指定的位置；

SEARCH，在一个目录路径中搜索资源。

PROPFIND，获取与指定资源有关的信息，如作者、大小与内容类型。

TRACE，在响应中返回服务器收到的原始请求。可以使用这种方法避开阻止跨站点脚本的防御

11.2解决方案

  1. 在 xxxapplication.java 文件里加入
@BeanPublic ConfigurableServletWebServerFactory configurableServletWebServerFactory() {TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();factory.addContextCustomizers(context -> {SecurityConstraint securityConstraint = new SecurityConstraint();securityConstraint.setUserConstraint("CONFIDENTIAL");SecurityCollection collection = new SecurityCollection();collection.addPattern("/*");collection.addMethod("HEAD");collection.addMethod("PUT");collection.addMethod("DELETE");collection.addMethod("OPTIONS");collection.addMethod("TRACE");collection.addMethod("COPY");collection.addMethod("SEARCH");collection.addMethod("PROPFIND");securityConstraint.addCollection(collection);context.addConstraint(securityConstraint);});return factory;}

添加一个SecurityConstraint 往这个SecurityConstraint 里面加method， 加进去的method就是要被禁止的。

  1. 在应用程序的web.xml中添加如下的代码
<security-constraint><web-resource-collection><web-resource-name>fortune</web-resource-name><url-pattern>/*</url-pattern><http-method>PUT</http-method><http-method>DELETE</http-method><http-method>HEAD</http-method><http-method>OPTIONS</http-method><http-method>TRACE</http-method></web-resource-collection><auth-constraint></auth-constraint></security-constraint>

用于限制对资源的访问；
用于限制那些角色可以访问资源，这里设置为空就是禁止所有角色用户访问；
指定需要验证的资源
指定那些方法需要验证

12. 缺少"Content-Security-Policy"头

12.1风险描述

Content Security Policy，缩写 CSP，CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。CSP 大大增强了网页的安全性。攻击者即使发现了漏洞，也没法注入脚本。

12.2解决方案

1.通过 HTTP 头信息的Content-Security-Policy的字段。

在这里插入图片描述
2.通过网页的标签。

default-src 限制全局,默认所有都会使用这种规则
script-src：外部脚本
style-src：样式表
img-src：图像
media-src：媒体文件（音频和视频）
font-src：字体文件
object-src：插件（比如 Flash）
child-src：框架
frame-ancestors：嵌入的外部资源（比如、、和）connect-src：HTTP 连接（通过 XHR、WebSockets、EventSource等）
worker-src：worker脚本
manifest-src：manifest 文件
例如：
default-src ‘self’; 只允许同源下的资源
script-src ‘self’; 只允许同源下的js
script-src ‘self’ www.google-analytics.com ajax.googleapis.com;
允许同源以及两个地址下的js加载
default-src ‘none’; script-src ‘self’; connect-src ‘self’; img-src ‘self’; style-src ‘self’;
多个资源时,后面的会覆盖前面的

13. 缺少 X-XSS-Protection 头

13.1漏洞描述

跨站XSS防护，X-XSS-Protection

HTTP X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击 (XSS (en-US))时，浏览器将停止加载页面。

13.2解决方案

X-XSS-Protection: 0

X-XSS-Protection: 1

X-XSS-Protection: 1; mode=block

X-XSS-Protection: 1; report=&lt;reporting-uri&gt;

0

禁止XSS过滤。

1

启用XSS过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。

1;mode=block

启用XSS过滤。 如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。

1; report=&lt;reporting-URI&gt; (Chromium only)

启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面并使用CSP report-uri (en-US)指令的功能发送违规报告。

14. 缺少 X-Content-Type-Options 头

14.1风险描述

响应内容探测，X-Content-Type-Options

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

有些服务器响应内容未设置content-type，浏览器会自动检测内容type（MIME自识别：通过查看资源的字节来猜测正确的 MIME 类型），会出现编码相关的安全问题（IE和chrome会忽略content-typ自行推测网页格式、编码等）

14.2解决方案

服务器配置响应头：X-Content-Type-Options: nosniff

15. 自动填写未对密码字段禁用的 HTML 属性

15.1漏洞描述

密码字段没有强制禁用自动填写功能。

15.2解决方案

input中添加属性：autocomplete=off

16.敏感信息泄露及错误处理

16.1风险描述

应用系统常常产生错误信息并显示给使用者，导致信息泄露问题，很多时候，这些错误信息是非常有用的攻击信息，因为它们暴露了应用系统实施细则或有用的开发信息，对攻击系统有很大帮助。

16.2解决方案

1、应根据业务特点定义出系统存储的敏感信息。

2、敏感信息在存储、传输、显示时应进行安全处理，可采用的处理方式为加密或脱敏。

3、敏感信息不应使用GET方式提交到服务器。

4、用户密码为最高级别的敏感信息，在存储、传输、显示时都必须加密。

5、需要选择可靠的加密算法，优先选择不对称加密算法，不得使用BASE64等编码方式进行"加密"。

6、对于一些系统默认报错页面应重新进行设计自定义报错页面，以免暴露系统敏感信息。

17. 发现数据库错误模式

17.1风险描述

主要是一些数据连接错误信息，通过提交特殊构造的字符，程序会暴露一些数据库信息，也容易引起SQL注入攻击。

17.2漏洞示例

在这里插入图片描述

17.3解决方案

1.加强输入数据的有效性验证，

2.轨范代码错误捕获及日志打印。

18.Cookie安全

18.1风险描述

Cookie作为用户身份的替代，其安全性有时决定了整个系统的安全性，Cookie的安全性问题主要如下所述：

（1） Cookie欺骗

Cookie记录了用户的帐户ID、密码之类的信息，通常使用MD5方法加密后在网上传递。虽然经过了加密处理，但是截获Cookie的人不需要知道这些字符串的含义，只要把别人的Cookie向服务器提交，并且能够通过验证，就可以冒充受害人的身份登陆网站，这种行为叫做Cookie欺骗。非法用户通过Cookie欺骗获得相应的加密密钥，从而访问合法用户的所有个性化信息，包括用户的E-mail甚至帐户信息，对个人信息造成严重危害。

（2）Cookie截获

Cookie以纯文本的形式在浏览器和服务器之间传送，很容易被他人非法截获和利用。任何可以截获Web通信的人都可以读取Cookie。Cookie被非法用户截获后，然后在其有效期内重放，则此非法用户将享有合法用户的权益。例如，对于在线阅读，非法用户可以不支付费用即可享受在线阅读电子杂志。

18.2解决方法

1、设置认证COOKIE时，增加Cookie httponly这个属性。如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息。

2、增加Secure这个属性。当该属性设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该cookie信息，所以不会被窃取到Cookie 的具体内容。就是只允许在加密的情况下将cookie加在数据包请求头部，防止cookie被带出来。secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取cookie后进行攻击。

19. 会话超时设置

19.1漏洞描述

浏览器和服务器之间创建了一个Session，若没有做会话超时设置，当客户端长时间（休眠时间）没有与服务器交互的情况下，服务器也没有将此Session销毁，若攻击者获取此会话，就能一直利用该会话，进行与服务器的交互。

19.2漏洞示例

下面一段存在漏洞的代码中，没有对session做一个失效的处理。

在这里插入图片描述

修复后的代码如下所示，用户在登录的时候，首先会让之前的session失效，然后又获取新的seesion。

在这里插入图片描述

19.3解决方案

设置空闲会话强制超时时间，时间不能设置过长，建议设置为5分钟。

设置Session超时时间方式：

方式一：

在web.xml中设置session-config如下：

2

即客户端连续两次与服务器交互间隔时间最长为2分钟，2分钟后session.getAttribute()获取的值为空

方式二：

在Servlet中设置

HttpSession session = request.getSession();

session.setMaxInactiveInterval(60);//单位为秒

20.日志处理

20.1风险描述

日志处理是由于在全局过滤的时候没有考虑日志文件内容，当一些敏感内容通过日志文件保存下来的时候，或者说木马病毒代码通过日志记录下来时，可以通过日志文件查看或执行。导致敏感信息泄露，甚至被上传webshell，导致攻击者可以随时进入后台，对文件进行操作。

20.2漏洞示例

1.日志文件中打印用户的用户名和密码。

2.日志中输出数据库信息。

3.保存恶意脚本。

20.2解决方案

对日志文件中的敏感内容进行转义，凡是从日志文件中输出的内容都要进行验证。而且对于一些敏感信息，如电话号码，密码，ip地址等内容都要进行加密保存。

21 HTTP响应头X-Frame-Options

21.1风险描述

X-Frame-Options HTTP响应头是用来确认是否浏览器可以在frame或iframe标签中渲染一个页面，网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。

攻击者可以使用一个透明的、不可见的iframe，覆盖在目标网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击iframe页面的一些功能性按钮上，导致被劫持。

21.2解决方案

X-Frame-Options可配置的三个参数:
1、DENY
表示该页面不允许在frame中展示，即便是在相同域名的页面中嵌套也不允许。
2、SAMEORIGIN
表示该页面可以在相同域名页面的frame中展示。
3、ALLOW-FROM uri
表示该页面可以在指定来源的frame中展示。
一般我们使用SAMEORIGIN

配置方式：
在服务端设置的方式如下：
Java代码:
添加拦截器设置：
response.addHeader(“x-frame-options”,“SAMEORIGIN”);
Nginx配置:
nginx.conf添加配置：
add_header X-Frame-Options SAMEORIGIN

Published by

风君子

独自遨游何稽首 揭天掀地慰生平

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注