1 在web应用程序中是什么导致安全性问题呢？一般有以下几个原因
1、复杂应用系统代码量大、开发人员多、难免出现疏忽
2、系统屡次升级、人员频繁变更，导致代码不一致
3、历史遗留系统、试运行系统等多个Web系统共同运行于同一台服务器上
4、开发人员未经过安全编码培训或者公司根本就没有统一的安全编码规范
5、测试人员经验不足或者没经过专业的安全评估测试就发布上线
6、没有对用户的输入进行验证：
1）永远不要信任用户的输入，要对用户的输入进行校验
2）数字型的输入必须是合法的数字
3）字符型的输入中对 编码符号要进行特殊处理
4）验证所有的输入点，包括Get，Post，Cookie以及其他HTTP头
2 web应用通常存在的10大安全问题
1、SQL注入
拼接的SQL字符串改变了设计者原来的意图，执行了如泄露、改变数据等操作，甚至控制数据库
服务器， SQL Injection与Command Injection等攻击包括在内
2、跨站脚本攻击（XSS或css）
跨站脚本(Cross-Site Scripting)是指远程WEB页面的html代码可以插入具有恶意目的的数据，当
浏览器下载该页面，嵌入其中的恶意脚本将被解释执行，从而对客户端用户造成伤害。简称CSS
或XSS
3、没有限制URL访问
系统已经对URL的访问做了限制，但这种限制却实际并没有生效。攻击者能够很容易的就伪造
请求直接访问未被授权的页面
4、越权访问
用户对系统的某个模块或功能没有权限，通过拼接URL或Cookie欺骗来访问该模块或功能
5、泄露配置信息
服务器返回的提示或错误信息中出现服务器版本信息泄露、程序出错泄露物理路径、程序查询
出错返回SQL语句、过于详细的用户验证返回信息。
6、不安全的加密存储
常见的问题是不安全的密钥生成和储存、不轮换密钥，和使用弱算法。使用弱的或者不带salt
的哈希算法来保护密码也很普遍。外部攻击者因访问的局限性很难探测这种漏洞。他们通常
必须首先破解其他东西以获得需要的访问。
7、传输层保护不足
在身份验证过程中没有使用SSL / TLS，因此暴露传输数据和会话ID，被攻击者截听，或使
用过期或者配置不正确的证书。
8、登录信息提示
用户登录提示信息会给攻击者一些有用的信息，作为程序的开发人员应该做到对登录提示信
息的模糊化，以防攻击者利用登录得知用户是否存在
9、重复提交请求
程序员在代码中没有对重复提交请求做限制，这样就会出现订单被多次下单，帖子被重
复发布。恶意攻击者可能利用此漏洞对网站进行批量灌水，致使网站瘫痪
10、网页脚本错误
访问者所使用的浏览器不能完全支持页面里的脚本，形成“脚本错误”，也就是网站中的脚
本没有被成功执行。遇到“脚本错误”时一般会弹出一个非常难看的脚本运行错误警告窗口
常见安全问题
- XSS攻击
- CSRF攻击
- SQL注入攻击
- 文件上传漏洞
- 信息泄露
- 越权
-
一、XSS攻击
定义：XSS (Cross Site Script)，跨站脚本攻击，因缩写和 CSS (Cascading Style Sheets) 重叠，所以叫 XSS。XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。
分类： - 存储型：注入的恶意代码存储在服务器上（常用于留言板、论坛帖子、CRM），受害者请求服务器获取信息的时候，这些恶意代码就被浏览器成功执行。 - 反射型：注入的恶意代码没有存储在服务器上，通过引诱用户点击一个链接到目标网站进行实施攻击。 - DOM型：注入的恶意代码并未显式的包含在web服务器的响应页面中，但会被页面中的js脚本以变量的形式来访问到的方式来进行实施攻击。
案例： - 存储型：论坛帖子界面input输入框中，输入<script>alert("xss")</script>进行提交。 反射型：在浏览器输入框中，输入
/xxx.php?name=<script>alert(/xss/)</script>- DOM型：
自测的方法：看见输入框就输入：<script>var temp = document.URL;var temp_new = temp+'test'document.write(decodeURI(temp_new));</script>
<script>alert("xss")</script>进行提交
预防措施： - 对 style、script、image、src、a 等不安全的因素进行过滤或转义 - 可以利用一些模板引擎避免 XSS 攻击，比如 Laravel 框架使用的 Blade，还有twig，Smarty 等 - 可以利用 HTTP-only，将 cookie 设置成 HTTP-only 防止 XSS 攻击
二、CSRF攻击
定义：CSRF（Cross-site request forgery：跨站请求伪造）是攻击者通过伪装成受信任的用户，盗用受信任用户的身份，用受信任用户的身份发送恶意请求。
预防措施： - 重要操作不使用GET - 让用户手工输入验证码 - 验证HTTP请求来源 - 使用框架机制，例如 laravel 的 csrf token机制
三、SQL注入攻击
定义：SQL注入攻击是通过WEB表单提交，在URL参数提交或Cookie参数提交，将怀有恶意的“字符串”，提交给后台数据库，欺骗服务器执行恶意的SQL语句。SQL注入的危害很大，利用SQL注入可以进行，拖库、删库、删表、UDF提权、读取文件等。
案例：
delete from user where id = ?;传入参数变量为` 1 or 1=1`执行注入后的Sql语句，可以返回 user 表的全部数据
预防措施： - 使用 pdo 对 sql 进行预处理，然后注入参数 - 使用框架，目前主流框架都对 SQL 注入问题做了封装处理
四、文件上传漏洞
定义：文件上传漏洞是攻击者上传了一个可执行的文件到服务器上执行，可执行文件包括有病毒、木马、恶意脚本等。
危害： 文件上传漏洞与SQL注入或XSS相比，其风险更大，如果存在上传漏洞攻击者甚至可以直接上传一个webshell脚本到服务器上。
预防措施： - 文件扩展名检测 - 文件 MIME 真实类型验证 - 文件重命名 - 文件目录设置不可执行权限 - 设置单独域名的文件服务器
五、信息泄露
定义：信息泄露主要指用户的手机号、邮箱、密码、身份证、地址等敏感数据泄露，还有服务器上的文件和环境变量等敏感数据泄露，还包括将直接将企业源码上传到开发平台等
案例： - 开发接口时，接口返回用户明文的手机号、身份证号码等 - 调试代码时，代码中提交了一些调试信息，未进行删除 - debug环境线上环境开启泄露服务器信息、数据库密码等 - 公司代码上传至公有版本库
预防措施： - 敏感数据脱敏（比如手机号、身份证、邮箱、地址）等 - 代码引入 CodeReview机制、debug是否开启、是否使用打印等泄露核心服务器信息的代码 - 定期从gitHub、码云等公有版本仓库检测是否泄露源码
六、越权
定义：超出了你自己所拥有的权限，干了你本来不可能干的事情。
分类： - 水平越权：用户A未授权可以访问用户B的数据。 - 垂直越权：未登录用户可以访问需要授权的应用。
预防措施： - 对于所有涉及到用户数据的操作，必须严格判断当前用户的身份。 - 对于所有需要权限控制的位置，必须严格检验用户权限级别。
七、设计缺陷
1、 返回信息过多
案例：登录时进行验证，当用户不存在时，返回用户不存在，当用户被禁用时，返回用户已被禁用。
预防措施： - 避免攻击者进行恶意尝试，不应该返回过多的信息，可以统一返回“用户名或密码错误”。
2、 短信接口被恶意攻击
案例：注册或登录时用户输入手机号码就可直接触发短信接口，这块最容易被攻击者进行短信轰炸。
预防措施： - 手机号、验证码参数校验 - 设置同一手机号短信发送间隔 - 设置每个IP地址每日最大发送量 - 设置每个手机号每日最大发送量 - 升级短信接口的验证方法、验证码机制引入等
3、 遍历
案例：使用数据库主键 id，作为业务 id 使用，外部爬虫根据主键轮训接口，爬取数据信息。
预防措施： - 数据库引入雪花id概念，对外业务接口使用雪花id作为业务id。
作者：MissLittleT
链接：https://www.nowcoder.com/discuss/613239
来源：牛客网
CSRF 跨站点请求伪造
- CSRF 跨站请求伪造（英语：Cross-site request forgery），是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。如：
- 攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
大多数用户并不能保证：
GET类型的CSRF
- GET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用：在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求复制代码
<img src=``"[http://bank.example/withdraw?amount=10000&for=hacker](http://bank.example/withdraw?amount=10000&for=hacker)">
- POST类型的CSRF:
- 这种类型的CSRF利用起来通常使用的是一个自动提交的表单，访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面
链接类型的CSRF：
攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。
CSRF与 XSS 区别
通常来说 CSRF 是由 XSS 实现的，CSRF 时常也被称为 XSRF
- 本质上讲，XSS 是代码注入问题，CSRF 是 HTTP 问题，XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行。CSRF 则是因为浏览器在发送 HTTP 请求时候自动带上 cookie，而一般网站的 session 都存在 cookie里面(Token验证可以避免)
XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。
CSRF防御
token；token 验证的 CSRF 防御机制是公认最合适的方案。但若网站同时存在 XSS 漏洞的时候，这个方法也是空谈
- 验证码；强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差
Referer check；请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险
XSS攻击
XSS全称cross-site scripting（跨站点脚本），是一种代码注入攻击，是当前 web 应用中最危险和最普遍的漏洞之一。攻击者向网页中注入恶意脚本，当用户浏览网页时，脚本就会执行，进而影响用户，比如关不完的网站、盗取用户的 cookie 信息从而伪装成用户去操作，危害数据安全。
XSS分类
反射型XSS（非持久性跨站攻击）
- 利用网站某些页面会直接输出请求参数的特性，通过在url的请求参数包含恶意脚本，诱使用户点击嵌入恶意脚本的url链接执行恶意脚本以达到攻击的目的。目前有很多攻击者利用论坛、微博发布含有恶意脚本的URL就属于这种方式。
- 比如访问链接：https://wqs.jd.com/index.html?content=alert(1)) 页面当中执行了，document.getElementById(“content”).innerHTML = content; 然而这个content是参数传过来的，那么就触发了反射型 XSS
- 存储型XSS（持久性跨站攻击）
- 通过表单输入（比如发布文章、回复评论等功能中）插入一些恶意脚本，并且提交到被攻击网站的服务器数据库中。当用户浏览指定网页时，恶意脚本从数据库中被加载到页面执行，QQ邮箱的早期版本就曾经被利用作为持久型跨站脚本攻击的平台。
- 与反射型 XSS 相比，该类的攻击更具有危害性，因为它影响的不只是一个用户，而是大量用户，而且该种类型还可进行蠕虫传播。
DOM Based XSS（基于 dom 的跨站点脚本攻击）
- 通过前面两种类型的方式，注入的脚本是通过改变 DOM 来进行攻击的。采用该种方式有一个好处就是从源代码中不易被发现。
- DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞
XSS攻击防范
产生xss攻击漏洞主要是因为服务器没有对用户输入进行编码和过滤。另一个原因是，这种攻击方法有很多变体，攻击的手法却不断翻新，要设计出一个能完全防御的XSS过滤器是非常困难的。
- 防范xss攻击的原则就是不相信用户输入的数据
- HttpOnly
- 将重要的cookie标记为http only, ，浏览器将禁止页面的 JavaScript 访问带有 HttpOly 属性的 Cookie。
- HttpOnly 主要是为了解决 XSS 之后的 Cookie 劫持，使用 HttpOnly 有助于缓解 XSS 攻击，防止被窃取敏感的 Cookie信息，本质上不是为了解决 XSS。
- 消毒
若有收获，就点个赞吧
0 人点赞
