我们在用户名中输入 ‘or 1=1#,密码随意。就变成了select name.passwd from users where username= ‘’ or 1=1#’ and password=???。在SQL语法中 # 是注释符,所以后面的语句都会杯注释掉,那么上面的语句就等价于select name.passwd from users where username=’’ or 1=1。在or 连接中, username=’’ 和 1=1 中有一个为真就为真。所以1=1肯定为真。如果存在sql注入的漏洞,则可以直接登录进去。
网站接受用户输入的链接,跳转到一个攻击者控制的网站,可能导致跳转过去的用户被黑客设置的钓鱼页面骗走自己的个人信息和登录口令。
未授权访问漏洞,是在攻击者没有获取到登录权限或未授权的情况下,不需要输入密码,即可通过输入网站控制台主页面地址或者不允许查看的连接便可进行访问,同时进行操作。
由于对登录的账号及口令校验存在逻辑缺陷,以再次使用服务器端返回的相关参数作为最终登录凭证,导致可绕过登录限制,如服务器返回一个参数作为登录是否成功的标准,由于代码最后登录是否成功是通过获取这个参数来作为最终的验证,所以。攻击者通过修改参数即可绕过登录的限制!
登录框处同样存在越权:
目录遍历漏洞是由于web中间件目录访问相关的配置错误造成的,该漏洞会泄露web应用程序的敏感路径、敏感的文件信息、网站的编辑器路径或测试接口、系统敏感目录等信息。
程序在实现上没有充分过滤用户输入的…/之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
分三类:反射型、存储型、DOM型 利用:获取cookie,钓鱼 这里我就不细说了
在登录框BP抓包,发现用户名、密码是明文传输的,即客户端与服务器的数据传输未加密。危害:攻击者可能通过劫持ARP欺骗、嗅探Sniffer、等手段截获敏感数据,若获取用户名和密码信息,可以进入到系统当中。漏洞挖掘:1、查看是否使用HTTPS协议 2、用户名、密码是否加密
利用:在登录框处输入手机号,密码,验证码随便填,BP抓包,尝试验证码爆破
下图作用是可以抓到返回包并可修改返回值:
任意账号密码重置的6种方法,这里深入讲一下:
修复建议:响应包中去掉短信验证码。
修改用户名、用户ID或手机号重置任意账号密码:
通过手机找回密码一般需要短信验证码验证。当我们输入正确的手机号和正确的短信验证码,然后进入重置密码的最后一步,也就是输入新的密码输入密码后提交到服务端的post数据包需要包含当前用户的身份信息。而一般网站是通过用户名或用户ID来标识用户身份的,如果这个用户名或用户ID没有和当前手机号、短信验证码进行绑定;也就是说服务端只验证用户名、ID是否存在,而不去验证用户和当前手机号是否匹配,那么我们就可以通过修改用户名、ID去修改其他用户的密码了。也可以修改的地方不限于找回密码的数据包,比如修改资料的地方也可能存在这样的漏洞。
修复建议:
用户操作个人信息时,服务端要对当前用户身份进行验证,防止越权操作;
用来标识用户身份的名称或ID可以使用自定义加密,也可以隐藏这些参数,直接从cookie中获取用户信息;
用户修改密码时应该先对旧密码进行验证,或者使用手机短信验证;
用户修改手机号时需要先对原手机号进行验证。
修复建议:服务端对验证码进行验证,结果为true时直接跳到下一步,无需向客户端单独返回验证结果;输入新的密码,然后提交到服务端,服务端应对当前用户名、手机号、短信验证码进行二次匹配验证,都为true时,才可以修改成功。
利用思路:第一步正常输入用户名,第二部输入任意验证码,直接访问输入新密码,重置密码。原因:当我们输入新的密码后,提交到服务端,服务端并没有对当前用户身份进行二次验证,只是简单的获取到用户名或ID以及新密码,从而导致跳过短信验证码验证重置任意账号密码。
修复建议:每一个步骤都要对前一个步骤进行验证;最后提交新密码时应对当前用户名或ID、手机号、短信验证码进行二次匹配验证。
修复建议:服务端对客户端提交的token值进行验证;保证token值使用一次后即失效,防止重复使用;对用户ID进行自定义加密;使用根据用户ID生成的token值来标识用户,链接中不携带用户ID。
修复建议:验证码满足一定复杂度,且限制验证码生效时间;验证短信验证码的数据包使用token值并验证,防止自动化工具爆破
短信炸弹是利用互联网第三方接口发送垃圾短信轰炸,只需输入手机号码就可以利用网络短信无限轰炸对方手机,具有恶意骚扰功能的软件。
上面讲到过了,例如:用BurpSuite爆破。
思路:登录接收验证码时,BP抓包,可以看到验证码回显在返回包中。
类似于弱口令,程序员开发为了方便,设置比较简单,例如8888、0000等。
验证码失效、未与用户绑定
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的"数据"拼接到SQL语句中后,被当作SQL语句的一部分执行,从而导致数据库被增、删、改、查的危害。
文章来源:https://blog.csdn.net/qq_45697116/article/details/124091560