注入
owasp排名第一的漏洞,有sql注入、LDSP注入、os注入。
产生注入的条件:
1. 用户可以控制输入
2. web系统未对用户输入进行严格过滤(一切输入都可能是有害的)
3. 用户输入被拼接到了代码中执行(违背了数据与代码分离的原则)
危害:
1. 网页篡改
2. 网页挂马
3. 数据库信息泄露
4. 写入后门,控制服务器
防御:
1. 一切输入皆可能有害,做好对用户输入的过滤。(前端js、正则表达式、关键词等的过滤)
2. 采用最小权限去运行程序
3. 当程序运行出错时,不要显示过多的报错信息。
失效的身份认证
攻击者通过身份认证、会话管理等的缺陷,破解或绕过密码,暂时或永久的冒充受害者。
补充:
1. 弱口令:tomcat的默认后台管理账号和密码为tomcat,如果不加修改,这可能和没有密码没有区别。
2. 万能密码,如 or 1=1之类的。
防御:
1. 使用强密码(大小写字母、数字、特殊字符)
2. 支持密码强制过期
3. 密码传输要进行加密(SSL、TSL)等
4. 支持账号禁用,防止攻击者利用已被攻破的账号继续做坏事。
5. 区分共有区域和受限区域。(公共区域允许匿名访问,受限区域仅允许指定用户访问)
失效的访问控制
已经通过认证的用户可以访问自己不应该能访问的数据做特权用户可以做的操作,比如低特权访问高特权等。
问题:
1. 文件包含、目录遍历
2. 权限绕过(水平越权):用户未经过身份验证访问资源,或注销后仍可访问资源,对不同用户访问的资源没有做很好的校验,如标准用户可访问管理员资源,或访问其他用户私有资源等。
3. 权限提升(垂直越权)
防御:
1. 除公有资源外,默认情况下拒绝访问。
2. 使用一次性的访问控制机制,并在整个应用程序中不断重用它们,包括最小化CORS使用。
3. 记录失败的访问控制,并在适当时向管理员告警(如:重复故障)。
4. 当用户注销后,服务器上的JWT令牌应失效。
5. 使用强访问控制模型。
敏感数据泄露
医疗、财务、行程等数据可能是敏感的,攻击者可以通过手机敏感数据发动攻击。
防御:
1. 根据业务定义敏感数据
2. 敏感数据的显示、传输、存储要进行加密或脱敏处理。
3. 用户密码属于最高的敏感数据,显示、存储要进行加密处理,如linux的用户密码就是hash处理后存在于/etc/shadow;用户密码的显示也采用原点代替。
4. 避免使用get提交敏感数据。
5. 加密的话最好采用非对称密码,如RSA(基于大素数难分解)。
不安全的反序列化
只了解过java的,所以只说java.
java序列化和反序列化:在网络上传输数据时,数据会转成二进制序列。因此当两个Java进程通信时要先将数据进行序列化,转化成二进制字节序列,大概接收到数据时,将字节序列进行反序列化,回复java对象。
反序列化漏洞原理:java中进行反序列化的是common-collections.jar,这个jar文件并未对二进制文件进行过滤而是直接反序列化,因此当攻击者将包含恶意代码的二进制字节流发至服务器,服务器将其反序列化导致恶意代码执行。
补充:
1. Weblogic JAVA反序列化漏洞
2. JBoss java反序列化漏洞
危害:
1. 远程代码执行
2. 重放攻击
3. 注入攻击
4. 权限提升
防御:
1. 不接受来自不受信源的序列化对象。
2. 反序列化之前做好严格的数据检验。
3. 隔离运行在低特权环境中反序列化的代码
XSS
另一种形式的注入(js/html的注入)。当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时,或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时,就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本,并劫持用户会话、破坏网站或将用户重定向到恶意站点。
分类:
1.反射型
2.存储型
3. DOM型
防御:
1. HttpOnly防止截取cookie
2. 过滤、转义用户输入的数据
3. 使用web防火墙等安全设备或软件在外围进行检测和防护
安全配置错误
多为不安全的默认配置、不完整的临时配置等。
防御
1. 使用的服务不包含不必要的功能、文档、组件等。
2. 及时检测系统服务版本,为已发现的漏洞打补丁。
3. 对文件分配权限时遵守最小权限原则。
使用含有已知漏洞的组件
如IIS6.0,Strcts2的低版本等等。
组件拥有和程序相同的权限,组件出现了漏洞,容易成为突破口导致整个程序受攻击。
防御:
1. 官方渠道获取组件
2. 越复杂的系统出错的概率越大,所以移除不必要的组件。
3. 及时留意组件的更新和相关漏洞的发布,及时打补丁。
不足的日志记录和监控
不足的日志记录和监控、应急响应不到位或者无效的集成,施工及能够进一步供给系统、保持持续性。
下列情况会导致不足的日志记录、检测、监控和响应:
1.未记录可审计性事件,如:登录、登录失败和高额交易。
2. 告警和错误事件未能产生或产生不足的和不清晰的日志信息。
3. 日志信息仅在本地存储。
4. 被扫描不发警告
防御:
1.确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去,并保留足够的用户上下文信息,以识别可疑或恶意帐户,并为后期取证预留足够时间。
2.确保日志以一种能被集中日志管理解决方案使用的形式生成
3.建立有效的监控和告警机制,使可疑活动在可接受的时间内被发现和应对。
4.建立或采取一个应急响应机制和恢复计划
XXE