安全编码

来源于公司 安全编码文档：

*****************sql 注入（MyBatis）:

1.#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号；

2.$将传入的数据直接显示生成在SQL中；

3.#方式能够很大程度防止 sql 注入，$方式无法防止；

4.$方式一般用于传入数据库对象，例如传入表名；

5.能用 # 就不用 $，若不得不使用${XXX}这样的参数，要手动地做好过滤工作，来防止sql注入攻击；

 

 

************sql 注入（Hibernate）:

密码输入框中输入 123 or 1=1

 

************************XSS：Cross Site Scripting,跨站脚本攻击；

攻击者往 web 网页里插入恶意 script 代码，当用户浏览该页时，嵌入web 里面的script 代码会被执行，从而达到恶意攻击用户的目的；

 

反射型：反射型 XSS（非持久型）一般指攻击者通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。

存储型：用户访问服务器-跨站链接-返回跨站代码。

DOM跨站（DOM XSS）：DOM（document object model文档对象模型），客户端脚本处理逻辑导致的安全问题。

 

修复方案：

method 1.编写过滤器;

method 2.设置 HttpOnly 以避免 cookie 劫持的危险；

method 3.引入 commons-lang（ commons-lang主要是针对java.lang包进行一些封装，提供一些工具类）；

method 4.org.springframework.web.util.HtmlUtils 可以实现 HTML 标签及转义字符之间的转换；

 

 

*******************************CSRF：cross site request forgery，跨站请求伪造，

 

XSS 利用的是站点内的信任用户；CSRF是通过伪装来自受信用户的请求来求利用受信任的网站；

CSRF攻击：攻击者盗用了你的身份，以你的名义向第三方网站发送恶意请求；

CSRF能做的事情包括利用你的身份发送邮件、发短信、进行交易转账等，甚至盗取你的账号；

 

CSRF防御：

1.尽量使用POST；

2.将cookie 设置为 HttpOnly；

3.在请求地址中添加 token，并验证；

4.验证 HTTP Referer 字段；

 

 

******************文件上传

问题产生的原因：在服务器端没有对用户上传的文件类型做校验或校验不完整，导致用户可以上传恶意脚本到服务器；

 

检查方法：

1.检查文件上传的功能点，是否对文件类型有判断、文件大小是否限制；

2.通过抓包工具绕过前端校验，对上传的文件名称、内容进行修改再上传；

 

导致结果：

文件上传成功后，存放文件的路径知道的情况下，访问上传的文件，代码会被解析执行；

 

上传漏洞防御：

1.判断文件类型时，结合使用 MIME Type，在后端严格控制可上传的文件扩展名，增加白名单模式，对不属于白名单内的不允许上传；（仅前端控制文件上传格式，可借助工具进行绕过）

2.上传文件的目录不允许有执行权限，不可解析 jsp、php、sh等脚本语言；避免直接访问上传文件从而执行脚本；

3.文件名随机命名。如使用 UUID，filename=UUID.randomUUID().toString()+houzhi；

4.不显示文件的绝对路径；

5.记录日志；

 

***************************路径操作

问题描述：通过用户输入控制系统文件操作所有的路径；

脆弱性分析：攻击者有机会获得系统文件的路径、从而访问或修改其他受保护的系统资源；

整改建议：

1.输入验证（即白名单）；

2.在服务端进行输入过滤，审查输入过滤非法字符的方法是否有效。过滤字符：.、./、../；

 

***********************访问控制

越权访问：是 web 应用程序中常见的一种漏洞；是指应用在检查授权时存在纰漏，攻击者使用较低权限的用户账号，利用绕过权限检查访问其他用户或更改权限；

 

产生原因：开发人员在对数据增删改查时，对客户端请求的数据过分相信而遗漏了权限的判定导致；

 

水平越权：是一种“基于数据的访问控制”设计缺陷引起的漏洞；

由于服务器端在接收到请求数据进行操作时没有判断数据的所属人而导致的越权数据访问漏洞；

 

垂直越权：是一种“基于URL的访问控制”设计缺陷引起的漏洞，又叫权限提升；

 

防御方法：

1.在每个页面加载前进行权限认证；

2.不能只更具用户ID去判断，应再次进行身份验证；

3.可以从用户的加密认证 cookie 中获取当前用户ID，防止攻击者对其修改。或在 session、cookie 中加入不可预测、不可猜解的 user 信息；

4.配置权限，应该使用“最小权限原则”，并使用“默认拒绝”的策略，只对有需要的主体单独配置“允许”策略；

 

*******************命令注入

攻击者可在目标系统上执行任意命令，如：删除服务器文件；（采用输入过滤，放置命令注入）

 

问题描述：程序中包含未经验证的命令语句，可能导致攻击者直接或间接控制所执行的命令；

脆弱性分析：攻击者执行恶意命令，可以盗取用户信息，执行恶意操作等；

 

整改措施：

1.使用白名单对输入进行验证，或使用黑名单对输入进行过滤，特别是 &、&&、|、||；

2.尽量不使用直接命令执行函数，或禁止外部参数传入该执行函数；

 

*******************密码管理

问题描述：

密码管理包括硬编码密码、空密码、配置文件中密码明文存储、对html 表单中的密码字段进行填充等；

 

脆弱性分析：

密码管理不当可能使非授权人访问密码保护的资源，导致系统信息泄露；

另外，对HTML表单中的密码字段进行填充会让让和人都能在HTML 源中看到他们的值，存储在密码字段中的敏感信息可能会被代理或浏览器缓存；

 

整改建议：

1.采用高强度的加密算法，如：国密算法、AES、RSA等；加密算法不能是 MD5、DES；

2.在HTML 表单中，禁止明文显示或自动填充；

 

**********************信息泄露

问题描述：

系统数据、调试信息、敏感信息泄露；

 

脆弱性分析：有助于攻击者了解系统并制定攻击计划；

 

整改建议：

1.限制对异常信息的打印（如 password）；

2.过滤敏感信息的输出；

3.敏感信息脱敏处理(如 用户手机号)；

 

**************************未验证的重定向和转发

问题描述：允许未验证的输入控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

 

脆弱性分析：该漏洞可以诱骗用户访问可信赖站点的 URL，并将他们重定向到恶意站点并获取用户敏感数据；

 

整改建议：

1.对于重定向和转发的URL这只白名单；

2.对传入到 URL 的数据进行验证；

3.不直接从输入中获取 URL；

 

**************************配置错误

**************************业务逻辑缺陷

1.同一个用户短时间内多次接收到同一站点/同一内容的短息；

2.通过获取短信验证漏洞，使系统遭到恶意扣费；

 

******************暴力破解

一般通过数据字典遍历的方法；

 

******************安全编码规范*************************

输入验证：

1.对所有输入的数据进行验证；

2.验证所有数据的类型、长度、范围；

3.尽可能采用“白名单”形式验证所有的输入；

4.任何潜在的危险字符必须作为输入，请确保执行了额外的控制；比如输入编码控制、特定安全API、以及在应用程序中使用的原因。常见的危险字符包括：<>" '%()&+||；

 

密码管理：

1.密码不应该在日志或控制台中显示；日志中避免使用 system.out.println()打印用户密码；

2.禁止使用私有或者弱加密算法（不允许使用易解密的MD5加密算法）；

3.禁止在源代码中直接写入密码；

 

会话管理：

1.不允许同一用户ID的并发登录；

2.为服务端的操作执行标准的安全会话管理，为每个会话执行合法的身份验证和权限控制，防止存在 CSRF跨站点请求伪造漏洞；

3.不要在 URL、错误信息或日志中暴漏会话标识符。会话标识符应当只出现在 http cookie 头信息中；

 

访问控制：

1.限制只有授权的用户才能访问受保护的应用程序数据；

2.限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源；

 

加密规范：

1.不要在错误响应中泄露敏感信息，包括：系统的版本信息、详细信息、会话标识或者账号等；

2.确保日志记录包含了重要日志事件数据，日志事件数据包括：时间戳、引发事件的账户或用户身份、请求的源IP地址、事件的结果（成功或失败）、事件描述；

3.不要在日志中保存敏感信息，包括：系统的版本信息、详细信息、会话标识或者账号等；

 

数据保护：

删除不需要的应用程序和系统文档，这些可能向攻击者泄密有用的信息；

 

数据库安全：

1.删除或修改所有默认的数据库管理员密码；

2.禁用任何不支持业务需求的默认账户；

3.应用程序应当以不同的凭证为每个信任的角色（比如：只读用户、访问用户、管理员）连接数据库；

4.连接字符串不应当在应用程序中硬编码，连接字符串应当存储在一个可信服务器的独立配置文件中，并且应当被加密；

 

文件管理：

1.通过检查文件报文头信息，验证上传文档是否是所期待的类型。只验证文件类型扩展是不够的；

2.关闭在文件上传目录的运行权限；

3.禁止将绝对文件路径传递给用户；

4.确保应用程序文件和资源是只读权限；

 

系统配置：

1.移除在HTTP 响应头中有关 web 服务版本和应用框架的相关信息；

2.禁用不需要的HTTP方法；