大家好，又见面了，我是你们的朋友全栈君。
Owasp top10
1.SQL注入
- 原理：web应用程序对用户输入的数据合法性没有过滤或者是判断，前端传入的参数是攻击者可以控制，并且参数带入数据库的查询，攻击者可以通过恶意的sql语句来实现对数据库的任意操作。
2.失效的身份认证和会话管理
- 原理：在开发web应用程序时，开发人员往往只关注Web应用程序所需的功能，所以常常会建立自定义的认证和会话方案。但是要正确的实现这些方案却是很难的。结果就在退出，密码管理，超时，密码找回，账户更新等方面存在漏洞。
- 危害：由于存在以上的漏洞，恶意用户可能会窃取或操纵用户会话和cookie，进而模仿合法用户。例如：窃取用户凭证和会话信息；冒充用户身份查看或者变更记录，甚至执行事务；访问未授权的页面和资源；执行超越权限操作。
- eg：用户身份验证凭证没有使用哈希或加密保护；
会话ID暴露在URL里（例如URL重写）；
3.跨站脚本攻击 XSS
- 定义：通常指黑客通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。一开始攻击是跨域的，所以称作“跨站脚本攻击”，但时至今日，由于js的强大功能以及网站前端应用的复杂性，是否跨域已经不再重要。
- 实施XSS攻击条件：1.需要向web页面注入恶意html代码.2.这些恶意代码能被浏览器成功执行。
根据XSS效果，分为以下几类：
- 反射型XSS（非持久型XSS）：给用户发送页面或者链接，让用户点击来进行攻击，也叫做“非持久型XSS”。
- 存储型XSS（持久型XSS）：把攻击存放在服务器，使每个访问的人都可能遭受攻击，主动性更强。
- DOM型XSS：本质上是反射型，但是是通过用户点击，修改原本dom元素的属性，构造攻击动作
- 反射型和dom型区别：
反射型是构造好了攻击动作，然后就等你打开那个页面；dom型也是等你点击，但是不是页面，而是通过用户动作，把原来的动作注释掉，然后加上自己修改的动作。
4.直接引用不安全的对象（IDOR）
- 定义：不安全的直接对象引用（IDOR）允许攻击者绕过网站的身份验证机制，并通过修改指向对象链接中的参数值来直接访问目标对象资源，这类资源可以是属于其他用户的数据库条目或者服务器系统的隐私文件等。
- 出现原因：1. web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限；2. 服务器上的具体文件名，路径或数据库关键字等内部资源暴露在URL或网页中，攻击者可以尝试直接访问其他资源。
5.安全配置错误：
- 定义：安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务，平台，web服务器，应用服务器，数据库，框架，自定义的代码等等。
- 影响：攻击者能够通过未修复的漏洞，访问默认账户，不再使用的页面，未受保护的文件和和目录来取得对系统的未授权的访问或了解。
6.敏感信息泄露：
- 成因：由于管理员或者技术人员等各种原因导致铭感信息泄露
- 解决：因此，我们需要对敏感数据加密，这些数据包括：传输过程的数据，存储的数据以及浏览器的交互数据。
7.缺少功能级的访问控制：
- 原理：Web应用程序的功能再UI显示之前，若没有验证功能级别的访问权限，攻击者能够伪造请求从而在未经适当授权时访问功能。
8.跨站请求伪造：
- 原理：1. 用户输入账户信息请求登录A网站。2. A网站验证用户信息，通过验证后返回给用户一个cookie。 3. 在未退出网站A之前，在同一浏览器中请求了黑客构造的恶意网站B。 4. B网站收到用户请求后返回攻击性代码，构造访问A网站的语句。 5.浏览器收到攻击性代码后，在用户不知情的情况下携带cookie信息请求了A网站。此时A网站不知道这是由B发起的。
- 攻击条件：a 用户访问站点A并产生了cookie b 用户没有退出A同时访问了B
-
CSRF分类：
GET型:
如果一个网站某个地方的功能，用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&password=123456,指用户id=1修改密码为123456，则攻击者 可以诱使用户点击链接，而此时用户正访问此页面，则账户密码会被修改为123456了。
POST型:
如果一个网站开发者的安全意识不够，使得攻击者获取到用户提交表单处理的地址，即可通过伪造post表单恶意提交（例如购买物品）造成损失。
- CSRF漏洞挖掘
- 抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在csrf漏洞
- 如果有Referer字段，但是去掉Referer字段后重新提交仍然有效，那么基本上可以确定存在CSRF漏洞。
- 防御手段：
- 验证http referer中记录的请求来源地址是否是合法用户地址（即最开始登录来源地址）
- 重要功能点使用动态验证码进行CSRF防护
- 通过token方式进行CSRF防护，在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击
9.使用含有已知漏洞的组件：
- 原理：大多数的开发团队并不会把及时更新组件和库当成他们的工作重心，更不关心组件和库的版本，然而应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，可能导致严重的数据丢失或服务器接管。
10.未验证的重定向和转发：
- 成因：在web应用中，没有对带有用户输入参数的目的url做验证。而这个时候攻击者就可以引导用户访问他们所要用户访问的站点（钓鱼网站）。此外还有获取信息，访问恶意网站，随意跳转，安装恶意软件等。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/140000.html原文链接：https://javaforall.net
