网站常见安全漏洞
1 什么是漏洞
数据泄露、服务瘫痪、成果失窃、系统劫持
2 服务端漏洞
2.1 第三方组件漏洞
防护方式：针对java可以使用dependency-check-maven检查项目组件是否存在安全漏洞
2.2 SQL注入
错误使用语言框架，或语言框架本身存在安全问题
例：1）使用mybatis-plus的危险函数，比如inSql，支持直接SQL拼接，存在SQL注入风险
2）mybatis使用#构建SQL模板（相当于直接拼接）
解决：用$不用#
3）Golang常见错误写法
防护方式：1）尽量不要基于DB的Raw方法拼接构造SQL语句，而应该使用预编译、ORM框架
“GORM 是面向 Golang 语言的一种 ORM(持久层)框架，支持多种数据库的接入，例如 MySQL，PostgreSQL，SQLite，SQL Server，Clickhouse。此框架的特点，弱化了开发者对于 SQL 语言的掌握程度，使用提供的 API 进行底层数据库的访问。”
使用gorm连接mysql：
package main
import (
"fmt"
"gorm.io/driver/mysql"
"gorm.io/gorm"
"time"
)
func main() {
// 参考 https://github.com/go-sql-driver/mysql#dsn-data-source-name 获取详情
//dsn := "user:pass@tcp(127.0.0.1:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local"
//db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
db, err := gorm.Open(mysql.New(mysql.Config{
DSN: "root:123456@tcp(192.168.168.101:3306)/gorm?charset=utf8&parseTime=True&loc=Local", // DSN data source name
DefaultStringSize: 256, // string 类型字段的默认长度
DisableDatetimePrecision: true, // 禁用 datetime 精度，MySQL 5.6 之前的数据库不支持
DontSupportRenameIndex: true, // 重命名索引时采用删除并新建的方式，MySQL 5.7 之前的数据库和 MariaDB 不支持重命名索引
DontSupportRenameColumn: true, // 用 `change` 重命名列，MySQL 8 之前的数据库和 MariaDB 不支持重命名列
SkipInitializeWithVersion: false, // 根据当前 MySQL 版本自动配置
}), &gorm.Config{})
if err != nil {
panic("failed to connect database")
}
// ----------------------------数据库连接池----------------------------
sqlDB, err := db.DB()
// SetMaxIdleConns 设置空闲连接池中连接的最大数量
sqlDB.SetMaxIdleConns(10)
// SetMaxOpenConns 设置打开数据库连接的最大数量。
sqlDB.SetMaxOpenConns(100)
// SetConnMaxLifetime 设置了连接可复用的最大时间。
sqlDB.SetConnMaxLifetime(time.Hour)
fmt.Println("success to link mysql")
select {}
}
作者：yumuing 链接：juejin.cn/post/724221… 来源：稀土掘金
2)使用ORM框架时，注意框架特性，可能存在不安全写法导致SQL注入问题
3）在复杂场景使用拼接SQL，需要对外部输入进行转义
2.3 命令执行
如果命令拼接没有做好安全过滤，将导致命令注入风险，服务器权限将被控制
防护方式：1）对动态值尽可能设置白名单进行验证
2）无法设置白名单时，对数据类型进行校验
3）特殊字符黑名单过滤或转义
2.4 越权漏洞
资源访问或操作时，主体权限没有进行校验。分为未授权、水平越权、垂直越权
水平越权：
黑灰产场景：订单查询功能可以通过orderId查询订单详细，攻击者遍历orderId获取其他用户的订单信息
防护：资源id尽量不要使用短id（遍历难度小），同时要资源属主校验
垂直越权：
黑灰产场景：攻击者开通测试管理员账户抓包获取接口，或通过逆向前端代码方式获取接口，然后绕过前端直接访问后端
防护：简单场景可以将接口在路由级别进行分组，对不同API分组引入Middleware（中间件）进行权限拦截。
2.5 SSRF 服务端请求伪造攻击
利用后端服务器向内网发出恶意请求
防护：对url的host设置白名单，若解析出的IP不是内网地址，则拒绝访问
2.6 文件上传漏洞
文件上传漏洞最直接的威胁就是上传任意文件，包括恶意脚本、可执行程序等。
一篇文章带你入门文件上传漏洞 - 掘金 (juejin.cn)
防护方式1）限制文件类型
2）站库分离：应用部署位置与上传文件分离
3）防止图床：对图片访问链接进行时间限制、访问身份限制等
3 客户端漏洞
3.1 开放重定向
重定向：某些网站需要重新定向到其他站点，所以在参数中携带url。
若程序逻辑没有控制好重定向范围，攻击者可以构造恶意连接，诱导用户到恶意站点。
修复：对重定向url设置白名单。
3.2 XSS 跨站脚本攻击
攻击者在web中插入恶意script
有用户输入的地方都可能遇到这种攻击，导致用户数据被读取
防护：1）输入过滤：禁止前端提交特殊字符
2）输出过滤
3）富文本场景
4）CSP：对当前站点能加载什么源的资源、发送什么请求进行限制
3.3 CSRF 跨站请求伪造
攻击者诱导用户访问恶意链接，执行用户非预期操作
例：
防护核心：判断请求来源
1）token：首次访问时，给客户端传递一个token，以后客户端每次访问都必须带此token才能访问
2）禁止某些场景发送第三方cookie
与当前网站的域名相匹配的 cookie 被称为第一方 cookie；来自当前网站以外域名的 cookie 被称为第三方 cookie。
“在 HTTP 响应头中，设置 Cookie 时，带上 SameSite 选项，可以防止第三方站点使用Cookie。
SameSite 选项通常有 Strict、Lax 和 None 三个值。
- Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方 Cookie。简言之，如果你从百度的页面中访问掘金的资源，而 掘金的某些 Cookie 设置了 SameSite = Strict 的话，那么这些 Cookie 是不会被发送到 掘金的服务器上的。只有你从 掘金的站点去请求 掘金 的资源时，才会带上这些 Cookie。
- Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
- 而如果使用 None 的话，在任何情况下都会发送 Cookie 数据。
严格程度分别是全部不允许第三方>仅允许GET请求>全部允许”
作者：精神科_江主任 链接：juejin.cn/post/685927… 来源：稀土掘金
3）检验Referer来源是否是合法站点
3.4 点击劫持
将恶意代码隐藏在诱导内容后
防护1）X-Frame-Options
“X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面是否可以在 , , 或者 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免 Clickjacking 攻击。”
作者：jessic_lin 链接：juejin.cn/post/684490… 来源：稀土掘金
2)CSP，设置白名单
3.5 CORS跨域配置错误
CORS：跨域资源共享
防护核心：设置白名单
