网络安全相关

JimmyYang_MJ

已于 2023-07-22 15:56:45 修改

阅读量2k

点赞数

分类专栏：安全文章标签： web安全安全

于 2020-03-27 14:35:51 首次发布

本文链接：https://blog.csdn.net/qq_41234094/article/details/105140697

版权

安全专栏收录该内容

1 篇文章 0 订阅

订阅专栏

参考博文https://blog.csdn.net/xuanyuan_fsx/article/details/104967382
https://blog.csdn.net/qq_33591903/article/details/83662061

一、数据库安全

1. SQL 注入

对于一个根据用户ID获取用户信息的接口，后端的SQL语句一般是这样：

select name,[...] from t_user where id = $id

其中，$id 就是前端提交的用户id，而如果前端的请求是这样：

GET xx/userinfo? id = 1%20 or %201=1

其中请求参数id转义后就是1 or 1=1，如果后端不做安全过滤直接提交数据库查询，SQL语句就变成了：

select name,[...] from t_user where id=1 or 1=1

其结果是把用户表中的所有数据全部查出

解决方法

1. 在JDBC中预先编译
	使用Statement的子类PreparedStatement，事先将sql语句传入PreparedStatement中，等会要传入的参数使用？代替，那么该sql语句会进行**预编译**，之后将前台获取的参数通过set方式传入编译后的sql语句中，那么此时被注入的sql语句无法得到编译，从而避免了sql注入的问题。而且使用PreparedStatement在一定程度上有助于数据库执行性能的提升
2. Mybatis
	mybatis通过使用#｛｝的方式，代表该语句在执行之前会经过预编译的过程，后来传入的参数通过占位符的方式填入到已经编译完的语句中。但使用$｛｝的参数会直接参与编译，不能避免sql注入。如果需求中非要使用到$｛｝的话，只能手动过滤了。
3. 手动过滤参数

声明一个危险参数数组danger，将前台传入的参数用“ ”分隔后，产生的参数数组与danger有交集时，终止该sql的执行，并反馈前台，提示禁止输入非法字符。

二、 web 安全

参考：https://www.cnblogs.com/itsuibi/p/10752868.html
https://zhuanlan.zhihu.com/p/398601816

1. CSRF

CSRF（Cross-site request forgery）：跨站请求伪造。

在这里插入图片描述

解决

方法一、Token 验证：（用的最多）

（1）服务器发送给客户端一个token；
（2）客户端提交的表单中带着这个token。
（3）如果这个 token 不合法，那么服务器拒绝这个请求。

方法二：隐藏令牌：

把 token 隐藏在 http 的 head头中。
方法二和方法一有点像，本质上没有太大区别，只是使用方式上有区别。

方法三、Referer 验证：

Referer 指的是页面请求来源。意思是，只接受本站的请求，服务器才做响应；如果不是，就拦截。

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP
请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问
http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆
bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的
URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF
攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御
CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example
开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF
攻击，拒绝该请求

2、XSS 攻击：

XSS（Cross Site Scripting）：跨域脚本攻击。

登陆接口安全

参考https://mp.weixin.qq.com/s?__biz=MzIwODkzOTc1MQ==&mid=2247485906&idx=1&sn=64eec4710ca95fcbdcb2326089b184cc&chksm=977a365aa00dbf4c0b464cff98501b230267eee6d7cf845f5dc1c90e2fb0bf6b5eed021c53d5&mpshare=1&scene=1&srcid=0901kAnfcqbIk1RfCmaNFfvV&sharer_sharetime=1598890646967&sharer_shareid=8cf244c7746138c29cc24186eb58530f#rd

登陆接口存在被暴力破解的安全问题

Flood 泛洪攻击

HTTP Flood
https://forum.huawei.com/enterprise/zh/thread-293931.html

SYN Flood 攻击是一种典型的拒绝服务型（Denial of Service）攻击。
【解决】 syn cookie

CC攻击

DDOS

https://www.cnblogs.com/wpjamer/p/9030259.html

防范

1. 使用验证码

缺点：
OCR

2. 登陆限制

登录时错误次数达到 10 次时，则 5 分钟内拒绝该账号的所有登录操作

缺点：
攻击者虽然不能获取到网站的用户信息，但是它可以让我们网站所有的用户都无法登录！

3. IP限制

设定某个 IP 下调用登录接口错误次数达到一定时，则禁止该 IP 进行登录操作。
（比如 niginx 的限流模块就可以限制一个 IP 在单位时间内的访问次数。）

缺点

比如现在很多学校、公司都是使用同一个出口 IP，如果直接按 IP 限制，可能会误杀其它正常的用户
现在这么多 VPN，攻击者完全可以在 IP 被封后切换 VPN 来攻击

4. 手机验证

可以结合上面三种使用，
例如：
当用户输入密码次数大于 3 次时，要求用户输入验证码（最好使用滑动验证）
当用户输入密码次数大于 10 次时，弹出手机验证，需要用户使用手机验证码和密码双重认证进行登录

Web 应用防火墙

中间人攻击

(man-in-the-middle attack, abbreviated to MITM)
解决方案：

HTTPS
用户名可以在客户端使用非对称加密，在服务端解密
密码可以在客户端进行 MD5 之后传输，防止暴露密码明文
操作日志，用户的每次登录和敏感操作都需要记录日志（包括 IP、设备等）
异常操作或登录提醒，有了上面的操作日志，那我们就可以基于日志做风险提醒，比如用户在进行非常登录地登录、修改密码、登录异常时，可以短信提醒用户
拒绝弱密码 注册或修改密码时，不允许用户设置弱密码
防止用户名被遍历 有些网站在注册时，在输入完用户名之后，会提示用户名是否存在。这样会存在网站的所有用户名被泄露的风险（遍历该接口即可），需要在交互或逻辑上做限制