网络数据传输安全性问题和常见的网络攻击

• 一. 常见的网络攻击与解决办法
  • 1. XSS攻击
  • 2. CSRF攻击
  • 1. SQL注入攻击
  • 2. 文件上传漏洞
  • 1. DDoS攻击
  • 2. 其他攻击手段
• 二. 数据传输安全性问题与解决办法
  • 1. 窃听
  • 2. 假冒
  • 3. 篡改
  • 4. 事后否认

 

一. 常见的网络攻击与解决办法

转自:https://blog.csdn.net/loongshawn/article/details/88047373 .

1. XSS攻击

  XSS（Cross Site Scripting）跨站脚本攻击，为了不与层叠样式表（CSS）混淆，故将跨站脚本攻击缩写为XSS。原理即在网页中嵌入恶意脚本，当用户打开网页时，恶意脚本便开始在用户浏览器上执行，以盗取客户端cookie、用户名、密码，甚至下载木马程式，危害可想而知。

  以一个表单输入举例说明

<input type="text" name="firstname" value="">

  在这里插入图片描述

  倘若用户在表单中输入恶意脚本，即对输入做些处理，如：

<input type="text" name="firstname" value=""/><script>alert("longlong")</script><!-- "/>

  就会出现以下结果：

  其实攻击的形式还有很多，比如将脚本伪装进URL，然后将URL进行URLEncode编码，当用户点击链接后，脚本就会被执行。

XSS防范：

  之所以会发生XSS攻击，是因为用户输入的数据变成了代码， 因此需要对用户输入的数据进行HTML转义处理，将输出的“尖括号”、“单引号”、“引号”之类的特色符号进行转义。

HTML	HTML转义后的字符
<	<
>	>
‘	&
“	"

2. CSRF攻击

  CSRF攻击的全称跨站请求伪造（Cross Site Request Forgery），通过盗用用户的身份信息，以你的名义向第三方网站发起恶意请求，若转账、盗取账号、发信息、邮件。流程框图如下：

  所以CSRF攻击一般场景是：
  1、用户登录受信站点A，生成本地cookie；
  2、用户没有退出站点A，访问了恶意站点B。

  CSRF攻击举例：恶意转账

Get请求
www.boc.com/transfer.do?accountNum=6233XXXX4324&money=10000
参数说明
accountNum转账目标账号
money转账金额

  如果银行系统利用上述接口转账，就用可能会被恶意网站攻击。当然上面仅是举例，银行安全等级不至于这么低，使用GET转账。比如银行升级接口为POST提交，当然这也不能解决根本的安全问题，黑客照样能够利用XSS漏洞植入恶意代码，请求转账接口。
  真实银行交易系统付款会有USB key、验证码、登陆密码、支付密码等一系列屏障，支付流程要复杂得多，安全系数也高很多。

CSRF攻击防御：

1、将cookie设置为HttpOnly

  CSRF攻击很大程度是利用了浏览器的cookie，为了防止站内XSS漏洞，cookie设置HttpOnly属性，JS脚本就无法读取到cookie中的信息，避免攻击者伪造cookie的情况出现。

2、增加token

  CSRF攻击之所以成功，主要是攻击中伪造了用户请求，而用户请求的验证信息都在cookie中，攻击者就可以利用cookie伪造请求通过安全验证。因此抵御CSRF攻击的关键就是，在请求中放入攻击者不能伪造的信息，并且信息不在cookie中。
  鉴于此，开发人员可以在http请求中以参数的形式加一个token，此token在服务端生成，也在服务端校验，服务端的每次会话都可以用同一个token。如果验证token不一致，则认为至CSRF攻击，拒绝请求。

3、通过Referer识别

  Http头中有一个字段Referer，它记录了Http请求来源地址。但是注意不要把Rerferer用在身份验证或者其他非常重要的检查上，因为Rerferer非常容易在客户端被改变。

（火狐的一个插件RefControl修改Referer引用）

1. SQL注入攻击

  SQL注入攻击就是把SQL命令伪装成正常的http请求参数，传递到服务端，欺骗服务器最终执行恶意的SQL命令，达到入侵目的。

SQL注入攻击原理如下：

String sql = "select * from user where nick = '" + nickname + "' and password = '" + password + "'";

  上述代码是校验用户名、密码是否有效，查询结果记录数大于0则表示有效。正常逻辑是用户名、密码匹配数据库记录；但攻击者会利用http参数进行SQL注入攻击，即password参数输入’ or ‘1’ = '1，导致SQL语句变为

select * from user where nick = 'zhangshan' and password = '' or '1' = '1';

  上述语句的执行结果就相当于用户能够绕过登录验证。

SQL注入防范

1、使用SqlParameter代替普通的字符串拼接

2、使用ORM框架

2. 文件上传漏洞

  倘若web网站没有对文件类型进行严格的校验，导致可执行文件上传到了服务器，恶意程序就会执行。
  为了避免恶意文件上传，需要对上传文件类型进行白名单校验，并限制文件大小，上传文件进行重命名。有关文件类型的校验，需要去了解下魔数（magic number）这个概念，这里不做引伸。

1. DDoS攻击

1、SYN洪水

  攻击者伪造大量无效IP，不断与目标主机建立TCP链接，导致服务器维护了一个非常大的链接等待列表，占用大量系统资源，直至新链接无法建立。
  这种攻击是利用了TCP三次握手的异常处理机制，即第三次握手，服务端在没有收到客户端ACK报文时，服务端会进行多次SYN+ACK重试，然后维护一个等待列表，而系统会为即将建立的TCP连接分配一部分资源。资源耗尽，系统也就无法再建立TCP连接。

2、DNS查询泛滥

  攻击者伪造大量无效域名，发送给目标服务器解析，这些域名均为无效域名，导致DNS服务器耗用大量资源去处理这些无效域名，造成DNS解析域名超时，达到攻击目的。

2. 其他攻击手段

  攻击手段永远都比防御方法多得多。因此平时的业务中需要及时的添加各种攻击防御策略。

二. 数据传输安全性问题与解决办法

1. 窃听

  A和B在互联网传输数据时，A向B发送的消息可能会在传输过程中被C偷看。C的行为称为“窃听”。

2. 假冒

  A和B在互联网传输数据时，B收到的消息不一定是A发送的，也有可能是C发送的。C的行为称为“假冒”。

3. 篡改

  A和B在互联网传输数据时，B收到的消息有可能被C截获并且进行来修改。C的行为称为“篡改”。

4. 事后否认

  A和B在互联网传输数据时，B收到了A的恶意信息，但是事后A不承认自己发送来恶意信息。A的行为称为“事后否认”

  解决办法： 点击此处了解以上数据传输安全问题的解决办法.