前端代码常见的安全缺陷（一）_前端空密码缺陷?

目录

1、使用不安全的target blank

问题描述：

修复建议：

2、Javascript 代码劫持

问题描述：

修复建议：

示例：

3、跨站请求伪造

问题描述：

修复建议：

4、遗留的调试代码

问题描述：

修复建议：

5、HTML页面中包含硬编码域名

问题描述：

修复建议：

6、密码管理：null 密码

问题描述：

修复建议

7、易受攻击的框架

问题描述：

修复建议：

8、请求头部未设置httpOnly属性

问题描述：

修复建议：

---

1、使用不安全的target blank

问题描述：

在使用<a>标签中使用target属性，当值设置为“_blank”攻击者会针对`window.opener`API进行恶意行为的攻击，有可能导致钓鱼安全漏洞问题。

例如，以下示例使用的`target`属性，但是没有设置`rel`属性。

    <a href="www.xxxxx.com" target="_blank" >test</a>

修复建议：

建议使用`target="_blank"`时，配合使用`rel="noopener noreferrer"`

例如，配置rel属性如下所示：

<a href="www.xxxxx.com" target="_blank" rel="noopener noreferrer">test</a>

2、Javascript 代码劫持

问题描述：

使用JavaScript传送敏感数据的应用程序可能会存在JavaScript劫持的漏洞，该漏洞允许未经授权的攻击者从一个易受攻击的应用程序中读取机密数据。

JavaScript劫持可以简单的理解为模拟授权的用户，窃取用户在服务器上的信息。Web浏览器使用同源策略(Same Origin Policy)，以保护用户免受恶意网站的攻击。同源策略规定：如果要使用JavaScript来访问某个网页的内容的话，则JavaScript和网页必须都来源于相同的域。若不采取同源策略，恶意网站便可以使用受害者的客户端凭证来运行 JavaScript，从其他网站加载的敏感信息，并对这些信息进行处理，然后将其返回给攻击者。

使用JSON传输数据的JavaScript应用更容易受到JavaScript劫持攻击。由于JSON使用JavaScript语法的子集表示对象、数组、简单值，JSON本身可以被当做JavaScript执行，且使用eval()函数对JSON数据结构求值早被认为是存在风险的，其可能执行恶意代码。

修复建议：

尽量避免跨域的数据传输，对于同域的数据传输使用xmlhttp的方式作为数据获取的方式。如果是跨域的数据传输，必须要对敏感的数据获取做权限认证，具体的方式可以包括：

1. referer的来源限制，利用前端referer的不可伪造性来保障请求数据的应用来源于可信的地方，此种方式力度较稀，完全依赖于referer，某些情况下(如存在XSS)可能导致被绕过。
2. 加入Token。利用Token对调用者的身份进行认证，这种方式对于调用者的身份会要求力度较细，但是一旦出现XSS也可能导致前端Token的泄露，从而导致保护失效。
3. 避免直接执行JavaScript响应：在响应中加入一些额外的字符。这些响应只有经过了修改，才能成功地转到JavaScript解释器进行处理。这样可以防止攻击者使用<script>标签来进行劫持。比如，可以给响应加上注释符号，使其无法直接执行；或者是在真实的响应前面，添加死循环语句，使其无法正常的直接运行。

示例：

function postXHR () {
        var xhr = new XMLHttpRequest();
        xhr.open('GET', './test.config', true)
        xhr.onreadystatechange = function () {
            if(xhr.readyState == 4) {
                if(xhr.status == 200 || xhr.status == 0) {
                    console.log(xhr.responseText)
                }
            }
        }
        try {
            xhr.send(null)
        } catch (error) {
            console.log('error', error)
        }
      }

以上代码示例，在代码扫描中，一直提示第三行关键词`open`有问题，然后根据建议，在请求头部添加token，或者Referer，或者在回调的时候，对返回值做xss过滤了，还是提示报错。

在这里可以换一种方式来实现，例如通过fetch API，或者支持异步请求的框架Axios等。

3、跨站请求伪造

问题描述：

跨站请求伪造(CSRF)是伪造客户端请求的一种攻击。应用程序允许用户提交不包含任何nonce（与用户Session关联的加密随机值）的请求，将可能导致CSRF攻击。
例如：以下代码片段用于银行转账功能，对于该重要敏感的操作没有进行相应防护，将易于导致跨站请求伪造攻击。

var req = new XMLHttpRequest();  
req.open("POST", "/transferFunds", true);  
body = "to_account=Bill&amount=10000";  
req.send(body);  

例2：下面是通过表单发送请求。

<form method="GET" action="/transferFunds ">
    cash: <input type="text" name="cash">   
    to: <input type=" text " name=“to">   
    <input type="submit" name="action" value="TransferFunds">   
</form>

修复建议：

防止跨站请求伪造攻击的方法如下：

1. 二次验证，进行重要敏感操作时，要求用户进行二次验证。
2. 验证码，进行重要敏感操作时，加入验证码。
3. 在重要敏感操作的表单中加入隐藏的Token。

例如：下面代码片段中，在表单中增加了一个Token。

req.open("POST", "/transferFunds", true);  
body = "to_account=Bill&amount=10000&token=" + token;  
//token为与会话相关的一次性随机数。  
req.send(body);  

这样，服务器端程序响应用户请求前先验证Token，判断请求的合法性。对于Token，越难被猜出攻击者攻击成功的概率就越低。

4、遗留的调试代码

问题描述：

应用程序中的测试代码会建立一些意想不到的入口，这些入口可能会被攻击者作为“后门”进行利。有的测试代码本身并不会带来危害，但它表明了程序未进行严格的清理，攻击者很可能会查找到另外一些可利用的测试代码。
例如：

console.log(123456789)

修复建议：

应用程序在发布之前应删除测试代码。

5、HTML页面中包含硬编码域名

问题描述：

HTML中引用其他网站的资源是非常危险的，如果攻击者入侵该网站域名，便可以篡改引用资源的内容。
例如：

<script src="https://apps.bdimg.com/libs/jquery/1.8.3/jquery.min.js"></script>

 

此段代码依赖网站https://apps.bdimg.com，如果攻击者入侵了此网站，则可以篡改jquery.min.js的内容，具有风险。

修复建议：

需要控制HTML文件所引用的js资源，尽量使用本地的资源，不要包含其他网站的js或其他资源。

6、密码管理：null 密码

问题描述：

null 密码会消弱系统的安全性。

例如：

var password = null;
var passwordCapability = null

修复建议

程序中不应采用null密码，程序所需密码应从配置文件中获取加密的密码值。

7、易受攻击的框架

问题描述：

在项目中可能引入的框架版本比较低，例如，使用jquery 1.8.3 的版本，以及使用它的功能，如下所示：

      $.ajax({
        url: "./test.config",   
        type: "GET", 
        async: true,
        success:  (json, status, error) => {
            console.log('jquery ajax', json);
        },
        error: function (xhr, status, error) {
            console.error(error);
        },
        });

修复建议：

根据最新jquery发现的漏洞，如果项目中有使用jquery的低版本，建议进行升级，最新发现的漏洞，在3.5.0 才得到修复，建议版本 >= 3.5.0 

8、请求头部未设置httpOnly属性

问题描述：

目前主流的浏览器都支持cookie的httpOnly属性，该属性设置为true的时候表示cookie只能由web服务器访问，如果不设置该属性的话默认为false这样攻击者就可以很容易的访问到cookie信息，从而获取authentication标记或者一些会话信息。
例如：下面代码段创建cookie，但是没有设置httpOnly属性。

var  info = {domain: 'secure.com', path: '/userInfo',secure:true};  
response.cookie("cookieName",data,info)  

修复建议：

在发送cookie的时候应该设置httpOnly属性，
例如：

var  info = {domain: 'secure.com', path: '/userInfo',secure:true,httpOnly:true};  
response.cookie("cookieName",data,info)