序号 | 漏洞类别
(一级) | 漏洞类别
(二级) | 安全设计&开发 |
|
1 | SQL注入 | SQL注入 | 漏洞简介:
本质：构造畸形的输入，从而改变原查询语句的语义
原因：系统后台对用户输入的参数未进行任何处理，直接代入SQL语句
漏洞危害：
数据库信息泄露、添加系统账号、读写文件获取Webshell等
防御策略:
1 权限最小原则
使用最小权限原则，避免root等高级账号在Web应用中的直接使用；
所用账号不应分配建立、删除数据库/表的权限(create table/drop table)，以及操作本地文件的权限；
2 严格过滤用户输入
严格审查包含select、union、delete、drop等SQL关键字的内容；
严格审查包含二进制数据、转义序列和注释字符的输入内容；
使用Web语言、数据库厂商提供的“安全函数”处理用户输入；
校验用户输入内容的大小和数据类型,强制执行适当的限制与转换；
3 使用预编译语句
Web应用程序使用预编译语句，绑定变量，是防范SQL注入的最佳方式 |
|
2 | XSS漏洞 | XSS漏洞 | 漏洞简介:
代码注入的一种。攻击者通过“HTML注入”的形式篡改了网页内容、插入了恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
漏洞危害:
窃取Cookie、XSS蠕虫、DDoS（JavaScript脚本能执行的功能都涵盖）
防御策略:
1 Coookie设置Httponly属性:避免XSS窃取用户Cookie。（浏览器会禁止页面的JavaScript代码读取带有HttpOnly属性的Cookie）
2 输入检查: 检查用户输入的数据是否包含一些特殊字符，如: <、 >、"、'等。可首先在客户端用JavaScript进行检查，但在服务器端必须再次检查一次，因为客户端的检查很容易绕过。其中，客户端检查可阻挡部分误操作的正常用户，节省服务器资源、避免安全产品误报。
3 输出检查:在输出数据之前，需对字符串进行编码处理。注意: 不同的输出位置应采用不同的编码方式:
(1) 输出到HTML普通标签、HTML普通属性中: 需要进行HTML实体编码,如: 使用 ESAPI 的 ESAPI.encoder().encodeForHTMLAttribute() 方法进行转码
& –> &
< –> <
> –> >
” –> "
' –> '
其中，普通标签指除script外的标签，普通属性指除href、src、style、action、on事件之外的属性
(2) 输出到中script标签、on事件属性中: 需要进行JavaScript编码, 如: 使用 ESAPI 的 ESAPI.encoder().encodeForJavaScript() 方法进行转码
(3) 输出到CSS(css文件、style标签、style属性)中: 需要进行CSS编码, 如: 使用 ESAPI 的 ESAPI.encoder().encodeForCSS() 方法进行转码
(4) 输出到URL(href属性)中: 需要进行URL编码，如:使用 ESAPI 的 ESAPI.encoder().encodeForURL() 方法进行转码 |
|
3 | 文件上传漏洞 | 文件上传漏洞 | 漏洞简介:
文件上传漏洞是指由于系统未对上传的文件进行严格的验证和过滤，导致用户可以越过其本身权限向服务器上传可执行的脚本文件,如:PHP、JSP、ASP等,并通过此脚本在服务端执行命令的一种攻击。
利用条件:
1、上传的文件能躲避服务端安全检查: 文件压缩、防火墙、安全狗等
2、攻击者能够访问到上传的文件路径: 文件路径 + 文件名
3、上传的文件能够被服务器解释执行: 脚本类型需要正确,文件夹所在路径被Web容器覆盖
漏洞场景:
1、前端文件上传限制被绕过
2、服务器配置不当直接上传
3、文件解析漏洞导致文件执行
4、服务端过滤不严或被绕过
5、文件路径截断上传
6、第三方应用漏洞导致文件上传，如:FCKEditor上传漏洞
7、开发框架漏洞导致文件上传,如: Struts2
防御策略:
1、上传目录设置为不可执行:Web容器不解析上传目录中的文件,即使攻击者成功上传Webshell,
服务器也不会执行脚本
2、在服务端严格判断文件类型: 以白名单形式进行"文件扩展名检查 + 文件头检查"
3、随机生成文件名和文件路径
4、单独设置文件服务器的域名 |
|
4 | CSRF漏洞 | CSRF漏洞 | 漏洞简介:
攻击者诱导当前已登录用户访问恶意网站，从而基于用户身份发送恶意请求、执行并非用户本意的敏感操作，如:账户转账、发表评论等。（请求是攻击者在恶意网站上构造的，用户访问时触发）
防御策略:
1 在敏感操作的HTTP请求参数中，添加随机的Token（推荐）
2 验证HTTP请求头中的Referer字段，用于判断请求来源是否是当前网站
3 在敏感操作处，添加图形验证码（影响用户体验）" |
|
5 | SSRF漏洞 | SSRF漏洞 | 漏洞简介:
服务端提供了从其他服务器获取数据的功能(如: 在线翻译、通过URL地址加载或下载图片),但没有对目标地址做过滤和限制。
防御策略:
1 协议限制: 限制请求的协议，仅允许http和https, 禁止file://,dict://,gopher://等协议
2 域名限制: 限制请求的域名或IP,避免应用被用来获取内网数据，攻击内网
3 端口限制: 限制请求的端口，仅允许访问,,,等端口
4 过滤返回的信息: 如果web应用是去获取某一种类型的文件，那么在把返回结果展示给用户之前先验证返回的信息是否符合标准 |
|
6 | 越权漏洞 | 水平越权、垂直越权 | 漏洞简介:
如果权限控制功能设计存在缺陷，那么攻击者就可以通过这些缺陷来访问未经授权的功能或数据，即存在越权漏洞。其中;
水平越权指的是攻击者尝试访问与他拥有相同权限的用户的资源;
垂直越权指的是一个低级别攻击者尝试访问高级别用户的资源。
防御策略:
五不要
1、不要认为用户不知道页面地址，而不对页面做权限检查
2、不要认为验证用户身份即可，还需验证权限
3、不要相信用户提交的任何参数，对于可控参数进行严格的检查与过滤
4、不要认为用户会按照程序流程进行操作
5、不要相信用户不会篡改客户端自动提交的数据
五要求：
1、前后端同时对用户输入信息进行校验，双重验证机制
2、执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限
3、多阶段功能的每一步都要验证用户权限
4、对于直接对象引用，加密资源ID，以防止攻击者对ID进行枚举
5、清晰的前后端交互接口文档，描述每个接口的权限要求，校验权限的位置 |
|
7 | 短信炸弹漏洞 | 短信炸弹漏洞 | 漏洞简介:
攻击者在网站提供的发送短信验证码的地方，对其发送的数据包进行重放或遍历不同的手机号，如果短信平台未做校验，系统会一直去发送短信，这样就造成了短信炸弹漏洞。
防御策略:
1、 对于同一手机号码，应限制发送短信的时间间隔和一天可发送的数量。如: 每1分钟仅允许发送一次，没超过1分钟，则不允许发送，提示操作频繁；
2、 在发送短信功能处，可增加图片验证码。系统服务端对验证码做校验，不一致则拒绝发送短信 |
|
8 | 弱口令漏洞 | 应用系统弱口令 | 开发注册、重置密码、修改密码功能时，需按照指定规则对用户密码复杂度进行校验，对不满足要求的密码需在前端给予提示信息，防爆破，登录异常情况下锁定账户，或开启多因子认证。 | 密码复杂度要求： |
9 | 应用系统管理员弱口令 | 开发重置密码、修改密码功能时，需按照指定规则对用户密码复杂度进行校验，对不满足要求的密码需在前端给予提示信息；第一次登录提示修改密码，按一定周期修改密码。防爆破，登录异常情况下多因子认证。 |
|
| 基础系统弱口令 | 在部署SSH、Redis、Mysql、Oracle、Weblogic等基础服务时，应避免使用弱口令或空密码的情况 |
|
| 外购产品弱口令 | 在部署外购产品时，需修改外购产品的默认口令，避免出现口令泄露的情况 |
|
| 任意密码重置 | 任意密码重置 | 漏洞简介:
该漏洞可能出现在用户忘记密码时的密码找回页面（为主）、或用户登录后重置密码的页面。
防御策略:
1 忘记密码时的密码找回页面:
（1）避免在将验证凭证（验证码）回显到前端页面、出现凭证泄露的情况
（2）在用户提交新密码后，需在服务端对用户标识、接收端（手机、邮箱）、凭证（验证码）进行关联性验证。
即: 验证重置用户与接收重置凭证的手机号/邮箱作是否一致、验证接收重置凭证的手机号/邮箱和发送的凭证是否一致，避免出现攻击者篡改重置用户、或篡改接收端（手机号/邮箱）的情况。
（3）需对凭证的有效尝试次数做限制，避免出现暴力猜测的情况
2 用户登录后重置密码的页面:
（1）在用户提交重置密码请求时，需在服务端对当前用户身份进行再次认证，避免攻击者篡改用户身份、水平越权的情况 |
|
| 敏感信息泄露 | 服务版本信息泄露 | 1、在部署WEB服务器的时候，应修改默认的banner图标信息，避免服务器版本信息的泄露
2、http返回信息中server等泄露，应修改不返回服务器信息
3、、、应用报错等泄露服务器版本信息，统一报错页面，应用报错信息转义后返回前端 |
|
| 错误页面信息泄露 | 报错信息中泄露服务器版本、异常调用栈，应设置统一的或等错误页面，避免将程序异常回显到前端页面，泄露敏感信息 |
|
| 前端页面信息泄露 | 1、html、jsp、js等返回前端的文件泄露测试提示、生产测试环境信息（ip）、默认账号信息、默认口令、接口信息、加密密钥、js第三方组件版本等，生产测试打包流程区分，js代码混淆；
2、前端未脱敏展示； |
|
| 用户敏感信息 | 未按照相关监管要求，在传输、展示过程中泄露了证件、密码、磁道等用户敏感信息，或者密码采用了弱加密算法加密，可还原 |
|
| 系统敏感路径泄露 | 禁止返回绝对路径，仅返回文件名 |
|
| 其他信息泄露 | Phpinfo信息泄露、DS_Store文件泄露、SVN\GIT文件泄露、配置文件泄露、ip泄露、BigIP泄露、 |
|
| 安全配置缺陷 | 启用危险HTTP方法 | 在部署网站时，应关闭不需要开放的HTTP请求方法（如: DELETE、PUT、OPTIONS等），仅保留GET、POST方法 |
|
| 错误配置CORS |
Access-Control-Allow-Origin设置不能为*
|
|
| HOST头攻击 | Nginx，修改ngnix.conf文件，在server中指定一个server_name名单，并添加检测。
Apache，修改httpd.conf文件，指定ServerName，并开启UseCanonicalName选项。
Tomcat，修改server.xml文件，配置Host的name属性。 |
|
| 传输层保护不足 | 1 对于涉及敏感数据的业务系统，强制使用HTTPS协议,以确保数据在传输过程中不会被泄露或窃取
2 如果使用HTTPS协议成本过高，可仅对敏感数据(登录、注册时的账号/密码)的传输进行加密处理 |
|
| 高危端口开放 | 禁止对互联网开放与业务系统无关的高危端口，如: 、等， |
|
| 暴力破解攻击 | 暴力破解攻击 | 漏洞简介:
攻击者通过系统地组合所有可能性（如:账户名/密码），以破解用户的账户名、密码等敏感信息的一种攻击。
防御策略:
1 登录功能处，使用验证码（保证一定的复杂度、避免验证码本身被破解）提高暴力破解攻击的成本
2 登录功能处，限制同一账号一定时间范围内的错误次数，尝试次数过多时，则锁定指定长度的时间 |
|
| 用户枚举漏洞 | 用户枚举漏洞 | 漏洞简介:
由于错误配置或设计缺陷，当向系统提交有效账户和无效账户时，服务器会有不同的响应。利用响应的不同，攻击者可以获取到系统已经存在的账户，进而可用于暴力破解、获取账户的登录密码。
防御策略:
在登录、修改密码、重置密码功能处，当用户账号/密码输入错误的情况下，应统一身份验证失败时的响应，如：用户名或密码错误。同时，可结合验证码机制进行防御（该漏洞通常伴随暴力破解攻击出现）。
在其他业务功能接口，当输入用户id不存在时，不应提示用户不存在；
注册功能处，限制同一ip的请求频率 |
|
| 点击劫持漏洞 | 点击劫持漏洞 | 漏洞简介:
点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。
防御策略:
1 设置X-FRAME-OPTIONS响应头: 该HTTP 响应头就是为了防御用 iframe 嵌套的点击劫持攻击（推荐）
DENY: 表示页面不允许通过 iframe 的方式展示
SAMEORIGIN: 表示页面可以在相同域名下通过 iframe 的方式展示
ALLOW-FROM: 表示页面可以在指定来源的 iframe 中展示
2 通过JavaScript防御: 通过JavaScript不允许当前页面被 iframe 嵌套。 |
|
| 未授权访问漏洞 | 未授权访问漏洞 | 漏洞简介:
攻击者无需通过身份认证，便可访问到本应登录后才可访问的敏感数据。
防御策略:
1、对网站下敏感URL进行登录状态检查
从session中获取登录成功时存入session中的身份标识，判断客户端传递过来的身份标识是否与session中保存的一致，不一致则跳转到登录页面或响应页面 |
|
| URL重定向/跳转漏洞 | URL重定向/跳转漏洞 | 漏洞简介:
URL跳转漏洞是指后台服务器在告知浏览器跳转时，未对客户端传入的重定向地址进行合法性校验，导致用户浏览器跳转到钓鱼页面的一种漏洞。
本质: 利用Web应用中带有重定向功能的业务，将用户从一个网站重定向到另一个网站。
危害: 诱导用户进入钓鱼网站、造成用户敏感信息泄露
防御策略:
1、对客户端传递过来的跳转URL进行校验
常用方式: 服务端配置跳转白名单或域名白名单，只对合法的URL做跳转 |
|
| 命令执行漏洞 | 命令执行漏洞 | 漏洞简介:
当应用需要调用一些外部程序时通常会用到一些执行系统命令的函数,当在调用这些函数执行系统命令时，如果对用户输入没有过滤或过滤不严，直接将其作为系统命令的参数拼接到命令行中，就会造成命令执行漏洞。
利用条件：
1、应用调用执行系统命令的函数，如PHP中的system、exec、shell_exec、passthru、popen、proc_popen等
2、将用户输入作为系统命令的参数拼接到了命令行中
3、没有对用户输入进行过滤或过滤不严
漏洞危害: 继承Web服务器程序的权限，去执行系统命令; 反弹shell等
防御策略:
1、尽量少用执行命令的函数或者直接禁用
2、在进入命令执行的函数或方法之前，需对参数进行过滤、对敏感字符进行转义
3、参数的值尽量使用引号包裹，并在拼接前调用addslashes进行转义（PHP语言） |
|
| 验证码缺陷 | 验证码不过期(复用)/绕过 | 1、验证码复杂度应满足一定规则，降低被自动化工具识别的比例
2、验证码需在服务器端生成，并在服务器端认证，避免前端绕过
3、在服务器端，只有在验证码检验通过后,才进行用户名和密码的检验
4、验证识别后，无论是否一致，都需将服务器上存储的验证码清空（销毁session中的验证码）
5、限制用户提交的验证码不能为空 |
|
| 业务逻辑漏洞 | 业务逻辑漏洞 | 业务逻辑设计不严谨，参数校验不严格，如流程绕过、顺序变更、异常值等 |
|
| 任意文件下载 | 任意文件读取下载（目录遍历） | 1、对文件名等相关字段进行校验。
2、禁止绝对路径访问，禁止”../”、“..\\”等访问上级目录字符串。 |
|
