Jsonp漏洞
0x01 漏洞描述
1、 一个众所周知的问题,Ajax直接请求普通文件存在跨域无权限访问的问题,甭管你是静态页面、动态网页、web服务、WCF,只要是跨域请求,一律不准。
2、 不过我们又发现,Web页面上调用js文件时则不受是否跨域的影响(不仅如此,我们还发现凡是拥有"src"这个属性的标签都拥有跨域的能力,比如
0x02 常见应用场景
1、 Callback、.json关键字搜索
2、 获取敏感信息
3、 content-type不严谨,callback返回xss代码然后html解析,Content-Type: application/json
4、 jsonp接口提供方被黑了
0x03 漏洞危害
0x04 修复建议
1、 验证来源(referer)
LDAP注入
0x01 漏洞描述
LDAP 注入是利用用户引入的参数生成恶意 LDAP 查询,通过构造 LDAP 过滤器来绕过访问控制、用户权限提升。在维持正常过滤器的情况下构造出 AND、OR 操作注入来获得敏感信息
0x02 常见应用场景
1、 AND注入-
2、 OR注入
3、 万能用户
0x03 漏洞危害
1、 登录绕过
2、 权限提升
3、 信息泄露
0x04 修复建议
1、 如&、!、|、=、<、>、,、+、-、”、’、;这些字符正常情况下不会用到,如果用户的输入中出现了,需要用反斜杠转义处理。
2、 还有些字符如(、)、\、*、/、NUL这些字符不仅需要用反斜杠处理,还要将字符变成相应的ASCII码值。
Xpath注入
0x01 漏洞描述
XPath 注入是指利用 XPath 解析器的松散输入和容错特性,能够在 URL、表单或其它信息上附带恶意的 XPath 查询代码,以获得权限信息的访问权并更改这些信息。XPath 注入与 SQL 注入类似,均是通过构造恶意的查询语句,对应用程序进行攻击
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
数据提交到服务器上端,在服务端正式处理这批数据之前,对提交数据的合法性进行验证。
检查提交的数据是否包含特殊字符,对特殊字符进行编码转换或替换、删除敏感字符或字符串。
对于系统出现的错误信息,以IE错误编码信息替换,屏蔽系统本身的出错信息。
参数化XPath查询,将需要构建的XPath查询表达式,以变量的形式表示,变量不是可以执行的脚本。如下代码可以通过创建保存查询的外部文件使查询参数化:declare variable $loginID as xs:string external; declare variable p a s s w o r d a s x s : s t r i n g e x t e r n a l ; / / u s e r s / u s e r [ @ l o g i n I D = password as xs:string external; //users/user[@loginID= passwordasxs:stringexternal;//users/user[@loginID=loginID and @password= $password]。
通过MD5、SSL等加密算法, 对于数据敏感信息和在数据传输过程中加密, 即使某些非法用户通过非法手法获取数据包,看到的也是加密后的信息。
SQL 注入
0x01 漏洞描述
SQL注入漏洞产生的原因是网站应用程序在编写时未对用户提交至服务器的数据进行合法性校验(类型、长度、业务参数合法性等),同时没有对用户输入数据进行有效地特殊字符过滤,使得用户的输入直接带入数据库执行,超出了SQL语句原来设计的预期结果,导致了SQL注入漏洞。
0x02 常见应用场景
SQL注入漏洞可能出现在一切与数据库交互的地方,比如常见的查询用户信息、查询订单信息等查询处;搜索、筛选、过滤等;更新用户信息、添加备注等。另外,其他日志记录、分析等处也可能出现,比如记录用户登录处,记录用户登录日志处;比如常见的请求头中的字段,UA、XFF等。
0x03 漏洞危害
- 获取数据库访问权限,甚至获得DBA权限;
- 获取其他数据库中的数据;
- 盗取用户的机密信息包括账户、个人私密信息、交易信息等等;
- 运行各种操作系统命令;
- 通过构造特殊的数据库查询语句,可操作数据库进入后台并插入木马,以获取整个网站和数据库的控制权限;
- 篡改、删除网站页面;
- 数据库所在服务器被攻击从而变为傀儡主机,甚至可能导致局域网(内网)被入侵;
0x04 修复建议
4.1 代码层面
4.1.1 输入验证
类型判断:字符型、整型;
长度判断:设置最大长度值;
业务参数合法性判断:比如支付金额不可能为负值这种;
特殊字符过滤:比如’,",\,<,>,&,*,;,#,select,from,where,sub,if,union,sleep,and,or等;
验证所有的输入点,包括UA、Cookie以及其他HTTP头;
4.1.2、预编译处理&参数化查询
所有与数据库交互的业务接口均采用参数化查询,参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中,参数化查询是防御SQL注入的最佳方法,比如:Java中的PreparedStatement,PHP中的PDO等。
4.2 数据库层面
4.2.1 最小权限原则
遵循最小化权限原则,严格限制网站用户的数据库的操作权限,禁止将任何高权限帐户(sa,dba、root等)用于应用程序数据库访问,从而最大限度的减少注入攻击对数据库的危害。
4.2.2 禁用敏感函数
比如MSSQL中,拒绝用户访问敏感的系统存储过程,如xp_dirtree,xp_cmdshell等。
4.2.3 权限控制
限制用户所能够访问的数据库表。
4.2.4 编码统一
网站与数据层的编码统一,建议全部使用UTF-8编码,避免因上下层编码不一致导致一些过滤模型被绕过,比如宽字节注入等。
4.3 其他措施
- 避免网站异常抛出SQL错误信息,比如类型错误、字段不匹配等,防止攻击者利用这些错误信息进行一些判断;
- 使用通用防注入系统;
XSS
0x01 漏洞描述
XSS全称为Cross Site Scripting,为了和CSS分开简写为XSS,中文名为跨站脚本。该漏洞发生在用户端,是指恶意攻击者往Web站点里插入恶意脚本代码,当用户浏览该网站时,嵌入其里面的脚本代码会被执行,从而达到恶意用户的特殊目的。
根据是否写入数据看来分类主要有反射性和存储型两大类。
• 反射型跨站脚本(Reflected XSS)
• 储存型跨站脚本(Persistent XSS)
区别:存储型XSS的恶意代码存在数据库里,反射型XSS的恶意代码存在URL里。
0x02 常见应用场景
2.1 反射型XSS
反射性XSS通常需要被攻击者点击对应的链接才能触发,且受到XSS Auditor、NoScript等防御手段的影响较大。
反射型xss应用场景:比如搜索、查询,接口调用,跳转,http头获取参数地理位置,cookie,id,referer等一切输入、输出的地方
2.2 存储型XSS
存储型XSS由于存储在数据库或其他持久性中间件中,所以用户只需浏览了包含恶意代码的页面即可在用户无感知的情况下触发。
反射型xss应用场景:比如注册处、用户名、地址、头像等信息,用户反馈、留言、修改个人信息、发表文章、评论、转发、私信等一切输入输出的地方。
0x03 漏洞危害
1. 钓鱼欺骗