前端常见安全性问题_前端安全问题

一、常见的安全性问题

1、XSS(Cross-Site Scripting)脚本攻击漏洞；
2、CSRF（Cross-sit request forgery）漏洞；
3、iframe安全隐患问题；
4、本地存储数据问题；
5、第三方依赖的安全性问题；
6、HTTPS加密传输数据；
7、SQL注入
8、文件上传漏洞

二、XXS攻击（Cross Site Scripting）（跨站脚本攻击）

## xss攻击

XSS(Cross Site
Scripting)，跨站脚本攻击。XSS是常见的Web攻击技术之一.所谓的跨站脚本攻击指得是:恶意攻击者往Web页面里注入恶意Script代码，用户浏览这些网页时，就会执行其中的恶意代码，可对用户进行盗取cookie信息、会话劫持等各种攻击.
例如：在表单提交时，输入js代码等或是增加提交请求时的网页，盗取信息

解决方法：

1. 输入过滤，对输入的数据进行严格校验，诸如< script >、< img >、< a >等标签进行过滤
2. 编码，一些常见的符号，如<>在输入的时候要对其进行转换编码，这样做浏览器是不会对该标签进行解释执行的，同时也不影响显示效果
3. 限制。通过以上的案例我们不难发现xss攻击要能达成往往需要较长的字符串，因此对于一些可以预期的输入可以通过限制长度强制截断来进行防御
4. HttpOnly Cookie，预防XSS攻击窃取用户cookie最有效的防御手段
5. CSP，原理其实就是白名单机制，开发者明确告诉客户端(浏览器)哪些资源可以加载并执行，我们只需要提供配置，其他的工作由客户端(浏览器)来完成。通过 < meta> 标签开启 < meta http-equiv=“Content-Security-Policy” content=“配置项” >
   配置项：

default-src：用来设置每个选项的默认值
script-src：外部脚本
style-src：样式表
img-src：图像
media-src：媒体文件（音频和视频）
font-src：字体文件
object-src：插件（比如 Flash）
child-src：框架
frame-ancestors：嵌入的外部资源（比如<frame>、<iframe>、<embed>和<applet>）
connect-src：HTTP 连接（通过 XHR、WebSockets、EventSource等）
worker-src：worker脚本
manifest-src：manifest 文件
block-all-mixed-content：HTTPS 网页不得加载 HTTP 资源（浏览器已经默认开启）
upgrade-insecure-requests：自动将网页上所有加载外部资源的 HTTP 链接换成 HTTPS 协议
plugin-types：限制可以使用的插件格式
sandbox：浏览器行为的限制，比如不能有弹出窗口等。
report-uri：有时，我们不仅希望浏览器帮我们防止XSS的攻击，还希望将该行为上报到给定的网址，该选项用来配置上报的地址
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

例子：

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
脚本：只信任当前域名
<object> 标签：不信任任何URL，即不加载任何资源
样式表：只信任 cdn.example.org 和 third-party.org
框架（frame）：必须使用HTTPS协议加载
其他资源：没有限制
1
2
3
4
5
6

三、CSRF安全漏洞（跨站请求伪造）

CSRF攻击

CSRF(Cross Site Request
Forgery)，即跨站请求伪造，是一种常见的Web攻击，但很多开发者对它很陌生。CSRF也是Web安全中最容易被忽略的一种
CSRF攻击的原理:CSRF攻击过程的受害者用户登录网站A，输入个人信息，在本地保存服务器生成的cookie。然后在A网站点击由攻击者构建一条恶意链接跳转到
B网站, 然后B网站携带着的用户cookie信息去访问B网站.让A网站造成是用户自己访问的假相,从而来进行一些列的操作,常见的就是转账.

解决方案:

1. 验证码,账户交易这种核心步骤，强制用户输入验证码，才能完成最终请求
2. Referer Check,HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，一般会带上Referer信息告诉服务器是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。
3. Anti CSRF Token,token校验，发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token 和cookie当中的token值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务，token可以在用户登陆后产生并放于session或cookie中，然后在每次请求时服务器把token从session或cookie中拿出，与本次请求中的token
   进行比对。

四、文件上传漏洞

上传漏洞在DVBBS6.0时代被黑客们利用的最为猖獗，利用上传漏洞可以直接得到WEBSHELL，危害等级超级高，现在的入侵中上传漏洞也是常见的漏洞。该漏洞允许用户上传任意文件可能会让攻击者注入危险内容或恶意代码，并在服务器上运行。
文件上传漏洞的原理：由于文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，导致允许攻击者向某个可通过 Web
访问的目录上传任意PHP文件，并能够将这些文件传递给 PHP 解释器，就可以在远程服务器上执行任意PHP脚本。

解决方法：

1. 检查文件类型及后缀
2. 定义上传文件类型白名单，即只允许白名单里面类型的文件上传
3. 文件上传目录禁止执行脚本解析，避免攻击者进行二次攻击

五、限制URL访问，越权访问

系统已经对URL的访问做了限制，但这种限制却实际并没有生效。攻击者能够很容易的就伪造
请求直接访问未被授权的页面

解决方法：

1. 在公共模块增加校验方式，查看是否具有对应权限
2. 监听路由跳转，在路由跳转之前，增加校验
3. 和后台联调，将对应的信息存入cookie，在数据访问时进行对比

六、不安全的加密存储

常见的问题是不安全的密钥生成和储存、不轮换密钥，和使用弱算法。使用弱的或者不带salt
的哈希算法来保护密码也很普遍。外部攻击者因访问的局限性很难探测这种漏洞。他们通常 必须首先破解其他东西以获得需要的访问。

解决方法：

1. 可以通过加密方式增加安全
2. 增加随机数，在请求头中指定随机数，切换请求从新生成
3. 增加公钥和私钥方式，定时更换
4. 对重复提交请求做限制

七、SQL注入攻击

SQL注入(SQL Injection)，应用程序在向后台数据库传递SQL(Structured Query
Language，结构化查询语言)时，攻击者将SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令.

解决方案:

1. 防止系统敏感信息泄露。设置php.ini选项display_errors=off，防止php脚本出错之后，在web页面输出敏感信息错误，让攻击者有机可乘。
2. 数据转义。设置php.ini选项magic_quotes_gpc=on，它会将提交的变量中所有的’(单引号)，”(双引号)，(反斜杠)，空白字符等都在前面自动加上\。或者采用mysql_real_escape()函数或addslashes()函数进行输入参数的转义。
3. 增加黑名单或者白名单验证。白名单验证一般指，检查用户输入是否是符合预期的类型、长度、数值范围或者其他格式标准。黑名单验证是指，若在用户输入中，包含明显的恶意内容则拒绝该条用户请求。在使用白名单验证时，一般会配合黑名单验证。

八、OS命令注入攻击

OS命令注入攻击指通过web应用，执行非法的操作系统命令达到攻击的目的。

如何防御

1. 后端对前端提交内容进行规则限制（比如正则表达式）
2. 在调用系统命令前对所有传入参数进行命令行参数转义过滤
3. 不要直接拼接命令语句，借助一些工具做拼接、转义预处理，例如Node.js的shell-escape npm包