目录
引言
1、弱口令
2、万能密码绕过
编辑
3、登录认证绕过
3.1.令牌刷新端的错误配置
3.2. 错误的sso配置
3.3.CMS个例的访问问题
3.4.JWT Token的错误解析
3.5.暴力修改Authentication
4、图形验证码不失效
5、短信验证码不失效
6、短信攻击
7、反射型跨站脚本攻击
8、SQL注入
9、任意用户密码修改/重置
10、敏感信息泄露
11、目录遍历
12、框架漏洞
引言
在网站后台登录的页面常用的渗透办法今天给大家分享一下，这样更好的让大家在日常维护网站的时候好注意在各个方便进行防御。
1、弱口令
测试方法：
可以手动测试例如下面的一些高频弱口令，2.根据网站所使用的第三方组件，寻找特定的弱口令或默认口令进行登录。或者直接BP走一波。一个6位数的纯数字密码使用保利破解仅需要3S即可。
admin:123456
admin:admin
admin:admin@123
admin:12345
test:test2022年安全部门统计发布的Top20弱口令排行榜：
2、万能密码绕过
测试方法：
(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 密码输入：任意asp aspx万能密码
1： "or "a"="a
2： ')or('a'='a
3：or 1=1--
4：'or 1=1--
5：a'or' 1=1--
6： "or 1=1--
7：'or'a'='a
8： "or"="a'='a
9：'or''='
10：'or'='or'
11: 1 or '1'='1'=1
12: 1 or '1'='1' or 1=1
13: 'OR 1=1%00
14: "or 1=1%00
15: 'xor
16: 新型万能登陆密码
用户名 ' UNION Select 1,1,1 FROM admin Where ''=' （替换表名admin）
密码 1
Username=-1%cf' union select 1,1,1 as password,1,1,1 %23
Password=1
17..admin' or 'a'='a 密码随便
PHP万能密码
'or'='or'
'or 1=1/* 字符型 GPC是否开都可以使用
User: something
Pass: ' OR '1'='1
jsp 万能密码
1'or'1'='1
admin' OR 1=1/*
用户名：admin 系统存在这个用户的时候 才用得上
密码：1'or'1'='1
3、登录认证绕过
测试方法：
1）直接访问内部URL。使用扫描工具找到含有admin、manager、administrator、login等词语的路径，尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
2）修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了，通过修改这些参数，从而被认为是已经认证过的用户。例如：http://www.xxx.xom/userinfo.jsp?authenticated=no，通过修改authenticated参数为yes，http://www.xxx.xom/userinfo.jsp?authenticated=yes，然后就可以通过认证，直接访问内部页面。
3）可猜测的SessionID。利用规律，猜测到一个有效的SessionID，然后通过修改请求中的SessionID为一个预测到的有效的SessionID，从而冒充会话的真正拥有着，绕过认证环节。
4）CSRF。利用CSRF漏洞在用户不知情的情况下，利用用户的会话进行敏感操作，从而绕过认证。
5）前端验证绕过：修改返回码,一般可以尝试true、success、200、0、1等3.1.令牌刷新端的错误配置
在这种情况下，用户使用有效凭据登录到应用程序，就会创建身份验证令牌进行身份验证。而此身份验证令牌在一段时间后过会过期。就在过期之前的这段时间内，通过 endpoint/refresh/tokenlogin 向服务器发送了一个包含 username参数的请求，此时返回包中就会出现有效 auth 令牌。
3.2. 错误的sso配置
随着平台的多样性，用户需求的不断提高，为了方便用户通过一次性用户身份验证登录多个应用程序和网站，大多数平台都会使用 SSO 系统。但是简单地使用 SSO 并不能自动保护系统: SSO 的配置也必须是安全的。
在这里，一个应用程序使用 Microsoft SSO 系统进行身份验证。当浏览internal.test.com网址时，浏览器会重定向到单点登录系统:
3.3.CMS个例的访问问题
像 WordPress、 Drupal 和 Hubspot 这样的CMS也需要进行安全配置，以免出现这样的漏洞。
这里举一个Liferay的例子，也是基于巧合遇到的。这应用有一个无需身份验证即可访问的登录页面。
Liferay使用 portlet 作为应用的sso，它在数字编号中有一个参数 p _ p _ id。对于Portlet来讲，可以通过将参数更改为值58来访问登录 Portlet。在普通登录页面上，只能访问登录页。但是，通过直接访问 Portlet，可以访问Create Account功能，然后允许self-registration功能访问后台内容，无需授权。
3.4.JWT Token的错误解析
JWT 令牌或 JSON Web Token在Web 中应用十分广泛。但是，虽然默认情况下它们有一个安全机制，就是密钥，但是后端服务器的解析机制够不够安全就不一定了。
曾有个网站使用的是JWT，当直接访问时，应用程序将用户重定向到 Microsoft SSO 网页。
但是，一些 JS 文件可以在没有身份验证的情况下访问。测试时发现应用程序使用 JWT 令牌，这些令牌在安全登录后通过Microsoft SSO系统发送。在后端机制中，存在一个安全错误配置，它没有检查是否是为特定应用程序生成的 JWT 令牌——相反，它接受任何具有有效签名的 JWT 令牌。这里使用微软网站上的一个 JWT 令牌示例:
3.5.暴力修改Authentication
在此案例中，通过 base64编码的 XML 请求发送到后端验证。在登录机制上，它将用户名、密码分别发送。Scode 参数中的值是密码的md5值。。请求中还有另一个有趣的标志: scode 有一个值为2。
最终发现，只要提供用户名和空密码就可以绕过认证。
4、图形验证码不失效
测试方法：
输入用户名、密码、验证码后，点击登陆按钮同时将数据包使用burpsuite进行拦截，并使用Repeater模块或Intruder模块进行数据重放，重新发送五次观察页面变化，是否会提示验证码输入错误等信息5、短信验证码不失效
测试方法：
1）请求发送短信，填写任意验证码，然后提交其他操作请求，将验证码参数置空或删除，测试是否可绕过检测；
2）尝试特权验证码，如000000、111111等；
3）同一个短信验证码是否能使用多次；6、短信攻击
测试方法：
1）手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。
2）通过利用burp或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到10条以上短信，如果收到大量短信，则说明存在该漏洞。
7、反射型跨站脚本攻击
测试方法：
1、GET方式跨站脚本：
在输入的参数后逐条添加以下语句，以第一条为例，输入http://www.exmaple.com/page.xxx?name=
文本输入框：需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同，可自行构造。
2、POST方式
例如：抓包对输入的参数进行构造语句触发XSS8、SQL注入
测试方法：
1）通过web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测，或者手工判断是否存在注入点，一旦确认存在漏洞，可利用自动化工具sqlmap去尝试注入。几种常见的判断方法：
a、数字型。
http://host/test.php?id=100 and 1=1 返回成功
http://host/test.php?id=100 and 1=2 返回失败
b、字符型。
http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失败
c、搜索型。
搜索型注入：简单的判断搜索型注入漏洞是否存在的办法是：
先搜索（’），如果出错，说明90%存在这个漏洞。
然后搜索（%），如果正常返回，说明95%有洞了。
然后再搜索一个关键字，比如（2006）吧，正常返回所有2006相关的信息。
再搜索（2006%‘and 1=1 and ‘%’=’）和（2006%‘and 1=2 and ‘%’=’）或者直接登录框输入用户名的后面输入’看是否报数据库错误
9、任意用户密码修改/重置
测试方法：
密码修改的步骤一般是先校验用户原始密码是否正确，再让用户输入新密码。修改密码机制绕过方式大概有以下三种：
1）如果输入新密码的接口可以直接访问，那么在未知原始密码的的情况下即可直接修改密码，通常知道了他人的用户名即可任意修改他人的密码。
2）如果系统未校验修改密码的用户身份，那么在提交修改密码请求时，攻击者通过输入密码，将用户名或者用户ID修改为其他人的，即可成功修改他人的密码。
3）当修改密码时系统需要电子邮件或者手机短信确认，而应用程序未校验用户输入的邮箱和手机号，那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码，以此修改他人的密码。10、敏感信息泄露
测试方法：
1）如果比较有耐心的话可以找一下页面源码、JS文件，全局搜索password,userlogin等一些敏感词等可能存在意想不到的收获
2）查找URL信息是为了找到账号密码验证成功后跳转的URL地址，然后尝试访问此地址，看是否出现未授权访问漏洞
此处已显示账号密码验证成功后的跳转地址，直接访问此地址看是否可以未授权访问。11、目录遍历
测试方法：
可以利用web漏洞扫描器扫描web应用进行检测，也可通过搜索，网站标题包含“index of”关键词的网站进行访问。12、框架漏洞
常见的框架漏洞如下所示：在这里就不一一给大家解释了。
Spring框架漏洞
Struts2框架漏洞
ThinkPHP 框架漏洞
shiro框架漏洞
