前言
搞安全的小伙伴只有一个登录框你都能测试哪些漏洞?
通常大家测试的都会测试关键部分,为了有更好的测试效果,小厂会提供给你用户名密码;但是一些比较重要的企业,而这个环境却是正式环境,里面存放着一些数据不希望被你看到的时候,是不会提供给给你登录账号的。这个时候,考验你基础知识是否扎实的时刻来临了。
用户名枚举
漏洞描述:
一般存在于系统登录页面,利用登陆系统中的漏洞可以试验出是否存在的哪些用户名,返回不同的出错信息可枚举出系统中存在的用户名。
测试方法:
找到网站或者web系统登录页面。在web系统登录页面,通过手工方式,利用系统中存在的用户名和不存在的用户名,密码随意,尝试登录,查看其回显内容。例如:输入存在的用户名admin,回显如下:密码错误;输入不存在的用户名test,回显如下:用户不存在。
示例:
风险分析:
攻击者根据Web应用程序返回的上述提示信息即可枚举系统中存在的登录用户名,然后针对枚举出来的登录用户名,对其密码进行暴力破解。
修复方案:
建议对网站登录页面的判断回显信息修改为一致:用户名或密码错误。
弱口令
漏洞描述:
有一部分厂商的设备存在默认的用户名以及密码(用户名以root、admin为主)
示例:
通常很多厂商后台默认账户为“admin”,密码为"admin"或“123456”,大家可以通过暴力破解去尝试
风险分析:
攻击者可利用互联网公开的常见弱口令尝试登录管理后台,对网站造成一定的影响。
修复方案:
禁止使用弱口令,口令应满足一定的复杂度(数字字母特殊符号,密码保持16位以上)。
给大家推荐一个随机生成密码的网站 https://suijimimashengcheng.bmcx.com/
空口令
漏洞描述:
找到网站登录页面,尝试输入用户名,密码为空进行登录。如果登录成功表示认证登录环节允许空口令
风险分析:
攻击者可利用该漏洞登录网站后台,操作敏感数据,甚至上传webshell,从而控制服务器。
修复方案:
判断输入密码是否为空,禁止空口令登录。
登录认证绕过
漏洞描述:
有的登录页面可以通过禁用js样式(不常见),能轻易的绕过登录认证,直接进入系统。或者是通过burp抓报改包进行登录绕过也是可以的(常见一点)
示例:
Apache shiro cve-2020-17523 Apache shiro较新的登录认证绕过,大概的方式就是使用空字符绕过
www.xxx.com/admin/%20/
www.xxx.com/admin/%2e/
示例用户名密码可以乱写
点击登陆按钮同时使用抓包工具进行数据包拦截
将数据包返回至当前页面,修改code值
登录成功
风险分析:
如果应用程序在认证上没有做好,可以导致恶意用户或者攻击者绕过认证,访问内部资源,这类漏洞通过防火墙和入侵检测系统很难预防。
修复方案:
可从以下几个方面预防认证绕过:
增加验证码,不使用前端验证,密码通过加密算法加密,失败次数多加锁,密码强度增加
存在暴力破解
漏洞描述:
就是用通过社工手段得到的信息随机组合的密码进行暴力破解,一般用户名密码都离不开身边的事物,并且网站密码字段是明文
测试方法:
找到网站登录页面。
利用burp对登录页面进行抓包,将其发送到Intruder,并设置其密码参数,如pwd=为变量,添加payload(字典),进行攻击,攻击过程中查看其返回的字节长度,来判断是否成功。
一般情况下,暴力破解有三种形式:
固定账号对密码暴力破解。
在得知账号具有规律性,或者通过某种方式获取到大量账号的前提下,固定密码对账号暴力破解。
使用网上流传的账号密码库进行撞库攻击。
示例:
风险分析:
攻击者一般会使用自动化脚本组合出常见的用户名和密码,即字典,再结合软件burpsuite的intruder功能进行暴力破解。
修复方案:
防止暴力攻击的一些方法如下:
增加验证码,密码通过加密算法加密,失败次数多加锁,密码强度增加
图形验证码不失效
漏洞描述:
有些网站登录框存在图形验证码,防止暴力破解攻击,但是正常的逻辑是前端输入验证码之后进行校验图形验证码的正确性,而后若是为真则进行登录操作,为假则返回验证码输入错误,而使用一次的验证码应该立即失效。然而有些网站验证码可能是可控的,输入一些特殊字符可能就能打到欺骗服务器或验证码使用一次之后并没有及时刷新
测试方法:
输入用户名、密码、验证码后,点击登陆按钮同时将数据包使用burpsuite进行拦截,并使用Repeater模块或Intruder模块进行数据重放,重新发送五次观察页面变化,是否会提示验证码输入错误等信息
示例:
此登录功能时存在图形验证码的,在输入了正确的图形验证码之后进行数据重放,发现图形验证码没有做到及时失效
修复方案:
1、系统在开发时注意验证识别后销毁session中的验证码。
2、限制用户提交的验证码不能为空
3、判断提交的验证码与服务器上存储的是否一致
短信验证码绕过
漏洞描述:
一些网站使用手机短信登录,短信验证码可被绕过或者是验证码过短可以被爆破。
测试方法:
1.请求发送短信,填写任意验证码,然后提交其他操作请求,将验证码参数置空或删除,测试是否可绕过检测;
2.尝试特权验证码,如000000、111111等;
3.同一个短信验证码是否能使用多次;
示例:
正确的逻辑应当是,短信验证码获取后,服务器校验短信验证码的来源以及有效性,使用一次后应该立即失效。但是我遇到的这个就是使用验证码登录后,注销用户登录后再一次使用验证码发现依然登陆成功,也就是短信验证码没有被删除
风险分析:
修改/重置密码、交易操作等功能通常需要短信验证码,若验证码可绕过,攻击者可利用该漏洞进行重置他人密码或转账等危险操作。
修复方案:
1.若存在特权验证码,建议将其删除;
2.应用服务端应严格校验验证码参数是否为空,格式是否正确;
3.关键操作每提交一次请求,应发送新的短信验证码,并且不可继续使用旧的验证码。
短信验证码可暴力破解
漏洞描述:
短信验证码位数太短或有效期太长导致可暴力破解
测试方法:
点击发送短信验证码,输入任意验证码,提交请求,使用burpsuite拦截请求,在intruder模块设置验证码参数为枚举变量,这是payload类型为numbers,对验证码进行暴力破解。
示例:
这里的短信验证码可被暴力破解,是因为并没有设置短信验证码使用错误几次后失效,故可被暴力破解
风险分析:
修改/重置密码、交易操作等功能通常需要短信验证码,若验证码可暴力破解,攻击者可利用该漏洞进行重置他人密码或转账等危险操作。
修复方案:
1.短信验证码不少于6位;
2.有效期不超过1分钟;
3.验证码错误次数超过上限应采取账户锁定策略。
短信攻击
漏洞描述:
短信攻击时常见的一种攻击,攻击者通过网站页面中所提供的发送短信验证码的功能处,通过对其发送数据包的获取后,进行重放,如果服务器短信平台未做校验的情况时,系统会一直去发送短信,这样就造成了短信轰炸的漏洞。
测试方法:
1、手工找到有关网站注册页面,认证页面,是否具有短信发送页面,如果有,则进行下一步。
2、通过利用burp或者其它抓包截断工具,抓取发送验证码的数据包,并且进行重放攻击,查看手机是否在短时间内连续收到10条以上短信,如果收到大量短信,则说明存在该漏洞。
示例:
点击获取验证码同时拦截数据包
使用burpsuite进行数据重放
风险分析:
攻击者通过填写他人的手机号,使用软件burpsuite的intruder功能重复提交发送短信的请求包,达到短时间内向他人的手机上发送大量垃圾短信的目的。
修复方案:
1、合理配置后台短信服务器的功能,对于同一手机号码,发送次数不超过3-5次,并且可对发送的时间间隔做限制。
2、页面前台代码编写时,加入禁止针对同一手机号进行的次数大于N次的发送,或者在页面中加入验证码功能,并且限制发送的时间间隔。
恶意锁定问题
漏洞描述:
通过不断的输入错误的密码可恶意锁定任意账号
测试方法:
针对测试账户,不断输入错误的密码,直至将其锁定
示例:
风险分析:
若系统认证功能无防自动化处理模块,攻击者可编写脚本批量锁定系统账号。
修复方案:
1.账户锁定之后应不能继续使用认证功能
2.认证功能防自动化操作,如添加图形验证码。
密码明文传输
漏洞描述:
认证过程中传输未加密(用户名密码等敏感数据明文传输)。
测试方法:
通过对网站登录页面的请求进行抓包,工具可用burp、wireshark、filder、等等,分析其数据包中相关password(密码)参数的值是否为明文。如图利用wireshark抓包分析的密码:
示例:
1.输入用户名密码
2. 使用burpsuite进行数据包拦截
风险分析:
攻击者通过在局域网中嗅探网络流量,获取明文传输的认证凭证,如用户名密码、SESSIONID等敏感信息。
修复方案:
建议按照网站的密级要求,需要对密码传输过程中进行加密得使用加密的方式传输,如使用HTTPS, 但加密的方式增加成本,或许会影响用户体验。如果不用 HTTPS,可以在网站前端用 Javascript 做密码加密,加密后再进行传输。
反射型跨站脚本攻击
漏洞描述:
跨站脚本攻击的英文全称是Cross Site Script,为了和样式表区分,缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上,在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击,它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的。已知的跨站脚本攻击漏洞有三种:1)存储式;2)反射式;3)基于DOM。
测试方法:
1、GET方式跨站脚本:
在输入的参数后逐条添加以下语句,以第一条为例,输入http://www.exmaple.com/page.xxx?name=
文本输入框:需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同,可自行构造,以及触发事件等切换,这里只列出了一些最常见构造语句。
示例:登录窗口用户名处存在反射型XSS注入
点击登陆,成功弹出内容
风险分析:
攻击者可以使用该漏洞构造钓鱼链接,诱骗受害者访问并填写用户名和密码,从而窃取用户的认证凭据
修复方案:
1、总体修复方式:验证所有输入数据,有效检测攻击;对所有输出数据进行适当的编码,以防止任何已成功注入的脚本在浏览器端运行。具体如下 :
2、输入验证:某个数据被接受为可被显示或存储之前,使用标准输入验证机制,验证所有输入数据的长度、类型、语法以及业务规则。
3、输出编码:数据输出前,确保用户提交的数据已被正确进行entity编码,建议对所有字符进行编码而不仅局限于某个子集。
4、明确指定输出的编码方式:不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。
5、注意黑名单验证方式的局限性:仅仅查找或替换一些字符(如"<" ">“或类似"script"的关键字),很容易被XSS变种攻击绕过验证机制。
警惕规范化错误:验证输入之前,必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤,一般建议过滤掉双引号(”)、尖括号(<、>)等特殊字符,或者对客户端提交的数据中包含的特殊字符进行实体转换,比如将双引号(”)转换成其实体形式”,<对应的实体形式是<,<对应的实体形式是>以下为需过滤的常见字符
万能密码
漏洞描述:
其实我觉得万能密码和sql注入应当区分开来,所以我就分开写了。
众所周知,登录处是一条查询操作,一些程序可能是没有注意到,就写成了
$result=mysqli_query($link,'select * from user'); #执行$sql命令,查询user列表行内容 $row=mysqli_fetch_assoc($result); #解析,通过用户名判断 里面行的内容密码是否正确 if ( $username===$row['username'] && $password === $row['password']) { echo '登陆成功'; $_SESSION['uid'] = $row['id'] ; header("Location:3.php?id=".$row['id']); } else{ echo '请重新填写账户或密码';
这个时候就可以构造特殊的sql语句进行截断,造成永真,这样的话就可以越过查询完成登录
测试方法:
(1)用户名输入: ‘ or 1=1 or ‘ 密码:任意
(2)Admin’ - -(或‘ or 1=1 or ‘ - -)(admin or 1=1 --) (MS SQL)(直接输入用户名,不进行密码验证)
(3)用户名输入:admin 密码输入:’ or ‘1’=’1 也可以
(4) 用户名输入:admin’ or ‘a’=‘a 密码输入:任意
(5) 用户名输入:‘ or 1=1 - -
(6) 用户名输入:admin‘ or 1=1 - - 密码输入:任意
(7) 用户名输入:1’or’1’=‘1’or’1’='1 密码输入:任意
示例:
这里的案例与上述的不太相同,他的查询多了一个判断动作,就是先判断用户名是否存在,存在的 时候才会进行下一步判断,判断用户名密码是否匹配,所以这里必须输入正确的用户名才行
admin’ or 1 #
点击登陆,成功登录
风险分析:
攻击者可通过万能密码直接登录后台,获取后台权限
修复方案:
1)对用户输入的特殊字符进行严格过滤,如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。
2)使用参数化查询(PreparedStatement),避免将未经过滤的输入直接拼接到SQL查询语句中。
3)Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分(如不能执行drop等),并设置Web应用中用于连接数据库的用户不允许操作其他数据库。
4)设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。
5)使用Web应用防火墙。
sql注入
漏洞描述:
通过组合sql语句,达到改变原来语句意思的攻击
测试方法:
1.通过web漏洞扫描工具对所有链接进行检测,或者手工判断是否存在注入点,一旦确认存在漏洞,可利用自动化工具sqlmap去尝试注入。几种常见的判断方法:
1)数字型。
http://host/test.php?id=100 and 1=1 返回成功
http://host/test.php?id=100 and 1=2 返回失败2)字符型。
http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失败
不同的SQL服务器连结字符串的语法不同,比如MS SQL Server使用符号+来连结字符串,而Oracle使用符号||来连结:
http://host/test.jsp?ProdName=Book’ 返回错误
http://host/test.jsp?ProdName=B’+’ook 返回正常
http://host/test.jsp?ProdName=B’||’ook 返回正常说明有SQL注入
2.如果应用程序已经过滤了’和+等特殊字符,我们仍然可以在输入时过把字符转换成URL编码(即字符ASCII码的16进制)来绕过检查。
修复方案:
SQL注入的主要原因是程序没有严格过滤用户输入的数据,导致非法数据侵入系统。
1)对用户输入的特殊字符进行严格过滤,如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。
2)使用参数化查询(PreparedStatement),避免将未经过滤的输入直接拼接到SQL查询语句中。
3)Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分(如不能执行drop等),并设置Web应用中用于连接数据库的用户不允许操作其他数据库。
4)设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。
5)使用Web应用防火墙。
任意用户密码修改/重置
漏洞描述:
可通过篡改用户名或ID、暴力破解验证码等方式修改/重置任意账户的密码。
测试方法:
密码修改的步骤一般是先校验用户原始密码是否正确,再让用户输入新密码。
密码重置机制绕过攻击方式主要有以下两种:
1.通过正常手段获取重置密码的链接,猜解链接的组成结构和内容(如用户名或者时间戳的MD5值)。在得知他人邮箱的情况下,构造重置他人密码的链接。
2.在得知他人手机号的情况下,通过穷举手机验证码重置他人的密码。
示例:
我遇到的密码重置漏洞,是忘记密码的时候会自动发送一条手机短信至绑定用户的手机中,而我做的则是在他发送之前拦截,而后修改手机号码,成功的接受到了手机短信,而后重置用户密码。
还有一种是手机短信验证成功后,重新设置密码时拦截数据包,通过修改类似username、userid等方式修改他人的账户密码。
风险分析:
密码修改功能常采用分步骤方式来实现,攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。
重置密码过程一般是首先验证注册的邮箱或者手机号,获取重置密码的链接(一般会包含一串唯一的字符串)或者验证码,然后访问重置密码链接或者输入验证码,最后输入新密码。密码重置机制绕过攻击是指在未知他人的重置密码链接或手机验证码的情况下,通过构造重置密码链接或穷举手机验证码的方式直接重置他人的密码。
修复方案:
1.及时对请求的用户身份与当前登录的用户身份进行校验,判断是否有权修改用户的密码并对原始密码是否正确也进行判断。
2.对原始密码进行了验证的情况下,限制输入原始密码的错误次数,防止攻击者暴力破解原始密码。
3.重置密码链接中的关键信息应随机化,不可预测(例如token机制),且禁止将关键信息返回到客户端。
目录遍历
漏洞描述:
目录浏览漏洞是由于网站存在配置缺陷,存在目录可浏览漏洞,这会导致网站很多隐私文件与目录泄露,比如数据库备份文件、配置文件等,攻击者利用该信息可以更容易得到网站权限,导致网站被黑。
测试方法:
可以利用web漏洞扫描器扫描web应用进行检测,也可通过搜索,网站标题包含“index of”关键词的网站进行访问。
示例:
一般目录遍历都是输入…/…/这种,或者通过御剑进行目录扫描,有的时候会有一些路径可以遍历里面的目录内容
风险分析:
攻击者通过访问网站某一目录时,该目录没有默认首页文件或没有正确设置默认首页文件,将会把整个目录结构列出来,将网站结构完全暴露给攻击者; 攻击者可能通过浏览目录结构,访问到某些隐秘文件(如PHPINFO文件、服务器探针文件、网站管理员后台访问地址、数据库连接文件等)。
修复方案:
目前存在该漏洞的常见中间件为apache和IIS,以下列出其相关的修复方式:
1、 IIS中关闭目录浏览功能:在IIS的网站属性中,勾去“目录浏览”选项,重启IIS。
2、 Apache中关闭目录浏览功能:打开Apache配置文件httpd.conf,查找“Options Indexes FollowSymLinks”,修改为“ Options -Indexes”(减号表示取消,保存退出,重启Apache。
3、 Nginx中默认不会开启目录浏览功能,若您发现当前已开启该功能,可以编辑nginx.conf文件,删除如下两行:autoindex on;autoindex_exact_size on;重启Nginx。
敏感文件信息泄漏
漏洞描述:
敏感数据包括但不限于:口令、密钥、证书、会话标识、License、隐私数据(如短消息的内容)、授权凭据、个人数据(如姓名、住址、电话等)等,在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。(这里的信息泄露,我包含了常见的已经类似于robots文件等等,包括入侵痕迹残留、打包备份文件遗留等等)
测试方法:
1、检测形式多样,工具爬虫扫描得到敏感文件的路径,从而找到敏感数据,
2、手工挖掘,根据web容器或者网页源代码的查看,找到敏感信息。
示例:
这里我给大家带来了最近比较火的锐捷信息泄露,在源代码中泄露了用户名密码信息
泄露了用户名以及MD5加密的密码
当然了还有一些奇葩的,会直接弹出来测试用户名密码、甚至是用户名密码自动填充等等我觉得只有这些才配成为信息泄露,剩下的泄露个什么加密方式、中间件版本信息啥的太边缘了,懒得测
风险分析:攻击者可通过上述方式获取网站敏感文件,收集网站敏感信息,从而有针对性的进行利用。
修复方案:
重要代码注意加密保护或者隐藏
框架漏洞
漏洞描述:
开发框架存在的漏洞,如Struts2框架漏洞、shiro等(weblogic反序列化中间件的就不写了)
测试方法:
以Struts2远程命令执行为例:
1.在了解网站所采用的结构框架后,除去伪静态页面,抓包或者读取页面源代码方式,查找到网站系统url为.do和.action结尾类型后,添加相应的远程命令执行代码进行判断。
例如用户可以在http://host.com/X.action?后添加相对应struts2 漏洞的远程命令执行代码,或者直接利用工具K8 Struts2 Exploit.exe进行检测
或使用shiro检测工具进行检测
示例:
使用burp插件进行被动检测
修复方案:
建议及时更新struts2的版本到最新
SSO认证缺陷
漏洞描述:
SSO认证存在缺陷,可越权登录他人账户。
测试方法:
1.信息传输缺乏安全保证
SSO认证通信过程中大多数采用明文形式传送敏感信息,这些信息很容易被窃取,致使重要信息泄露。另外,在通信过程中大多数方案也没有对关键信息进行签名,容易遭到伪装攻击。
2.Web服务的安全缺陷
由于单点登录基本上是基于Web服务实现的,所以也不可避免的存在Web服务的安全缺陷,如跨站脚本攻击、越权攻击等。
风险分析:
因为只需要登录一次,所有的授权的应用系统都可以访问,可能导致一些很重要的信息泄露。
修复方案:
建议从以下几个方面进行防御:
1.建议在不影响业务的前提下,使用HTTPS协议传输
2.严格校验SSO认证过程中的用户身份
3.过滤用户传入的参数,对特殊符号进行转义或屏蔽。
本文是我参照我的朋友鹏先生文章为例所写,在此特别感谢渗透大师鹏先生提供技术指导以及渗透心得,如和本文雷同不幸荣幸。
免责声明:本人坚决反对利用教学方法进行犯罪的行为,一切犯罪行为必将受到严惩,绿色网络需要我们共同维护,更推荐大家了解它们背后的原理,更好地进行防护。禁止任何人转载到其他站点,禁止用于任何非法用途。如有任何人凭此做何非法事情,均于笔者无关,特此声明。