![失效的身份认证和会话管理]( "失效的身份认证和会话管理")
通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
会导致非法登录，严重者可提权至管理员权限，甚至直接渗透内网，登录内网服务器。
（http://192.168.1．10/eweb/admin/login.jsp）
1.访问http://192.168.1．10/eweb/admin/login.jsp
2.发现为eweb编辑器后台，测试eweb编辑器后台默认口令 admin admin
1.针对管理人员，可强制其账号及密码强度必须达到一定的级别；
2.建议密码长度不少于8位，且密码中至少包含数字、字母和符号；
3.不同网站应使用不同的密码，以免遭受“撞库攻击”；
4.避免使用生日，姓名等信息做密码，可远离社工危害。
用户密码不满足复杂度要求，或密码规则太过简单，可通过猜解或字典破解的方式获取账户密码。
用户登录时未设置验证码或者未对登录次数做限制，可通过其他方式绕过验证，导致可以通过抓包改包，批量验证可能的账号及密码。
依据不同服务及用户权限，用户密码被破解后可造成用户密码被修改、数据泄露、挂马、服务器被远程控制等行为。
2.登录处可正常抓包，抓包内容账号密码为明文或者编码可识别；
建议对弱口令进行修改，设置口令策略:长度8位以上，包含数字、大小写字母、特殊符号；对必要的远程服务端口禁用默认用户登录，限制用户错误登录次数并在登录过程中添加验证码验证机制。
与SQL注入相同，没有对用户输入的内容进行严格过滤，导致用户可恶意构造SQL语句提交到后台执行，从而绕过身份验证。
依据不同Web系统及用户权限，用户验证被绕过后可造成用户密码被修改、数据泄露、挂马、服务器被远程控制等行为。
SQL语句sql=”select * from user where username=’”&username&”‘and pass=’”& pass&’” ，当我们用户名和密码都填写’or’=’or’提交的时候，即此时语句中的username和pass都等于’or’=’or’，那么，这条SQL语句就变成了：sql=”select * from user where username=”or’ ‘=”and pass=”or’ ‘=” ，自然也就通过了程序的验证。
16: 用户名 ’ UNION Select 1,1,1 FROM admin Where ”=’ （替换表名admin） 密码 1
建议修改Web应用服务的软件部分，增加对客户端提交数据（如表单、URL链接）的合法性验证，至少严格过滤SQL语句中的关键字，并且所有验证都应该在服务器端实现，以防客户端（浏览器前端）控制被绕过。
验证部分为get方法中URL后面跟的参数，及post方法中Post的数据参数，需过滤的关键字为：
[9]SQL关键字，如select，delete，drop等，注意对于关键字要对大小写都识别，如:select ;SELECT;seLEcT等都应识别。或者使用预处理执行SQL语句，对所有传入SQL语句中的变量，做绑定。这样，用户拼接进来的变量，无论内容是什么，都会被当做替代符号"?"所替代的值，数据库也不会把恶意用户拼接进来的数据，当做部分SQL语句去解析。
应用程序认证机制存在缺陷，可以导致恶意用户或者攻击者绕过认证，访问内部资源，这类漏洞通过防火墙和入侵检测系统很难预防。
1.网络嗅探。通过网络嗅探工具探测局域网中传输的明文用户名和密码。有些应用程序采用GET方式发送登录请求，可能导致GET的URL请求内容被缓存在代理服务器或着Web服务器端，导致用户名和密码泄漏。
2.默认或可猜测的用户账号。大多数开源软件或商业软件提供的基于网络配置和管理的接口，通常都会有一些默认的用户名和密码。例如，一般默认的用户名是：admin，administrator、root、system、guest等，而默认的秘密吗也根据硬件和软件的不同而不同，可尝试一下这些密码：password、admin、guest、12345等。
3.直接访问内部URL。使用Spider工具找到含有admin、manager、administrator、login等词语的路径，尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
4.修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了，通过修改这些参数，从而被认为是已经认证过的用户。
5.直接访问内部页面可猜测的SessionID。利用规律，猜测到一个有效的SessionID，然后通过修改请求中的SessionID为一个预测到的有效的SessionID，从而冒充会话的真正拥有着，绕过认证环节。
7.利用CSRF漏洞在用户不知情的情况下，利用用户的会话进行敏感操作，从而绕过认证。
1.对于每一个访问的URL都首先检查是否已经登录（不需要认证的URL除外，例如，帮助页面、免费下载页面等），如果没有登录，则跳转到登录页面；对于已经登录的用户，在退出的时候或者在会话很长时间处于idle状态的时候，需要保证原来的会话被正确的销毁并且不会再被重利用。
3.对于用户是否已经认证，禁止依赖客户端传过来的参数标识，将是否登录的标识保存在服务器端的会话中，当接收到该会话的请求时，从会话保存的状态判断是否登录。
4.对于SessionID一定要使用安全的随机数生成算法，使得SessionID不可预测。
OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。Oauth认证不完全，可越权登录他人账户。
OAuth的提供方提供OAuth授权过程中没有对回调的URL进行校验，从而导致可以被赋值为非原定的回调URL,甚至在对回调URL进行了校验的情况可被绕过。利用这种URL跳转或XSS漏洞，可以获取到相关授权token,危害到目标用户的账号权限。
如admin/123456/root/1qaz!QAZ；
2.通过代理拦截技术拦截登录请求，确定存在暴力破解可能性，然后点击“action”，发送到“Intruder”。
3.确认利用点，即：暴力破解的点，如账号或密码或账号和密码。将不需要的利用点去除。
针对两个位置进行测试，分别为账号和密码，因此“attack type”选择“cluster bomb”方式，这个攻击方式将逐一将负载1中的元素与负载2中的所有元素进行组合形成测试请求。
5.设置攻击负载。负载集选择“runtime file”，即可指定自定义字典文件，点击“select file”选择提前制作好的字典文件。
7.结果判定。结果判定要根据成功请求特点进行综合判定，有时仅仅通过状态码即可，有时需要根据返回页面的内容，本示例就需要查看登录网页页面进行判定，下图为提交的测试请求及返回的相关信息。
各应用除了验证access token之外，还必须辅助其他参数进行判断（比如自行加入其它认证参数进行双重认证）；另一种方法则是验证access token背后所属的应用app key的唯一性和对应性（无论是自行验证还是开放平台通过签名等形式帮助验证），确保该access token是该应用的。
通过伪造IP地址能够绕过应用IP地址限制，访问和执行系统相关功能。
没有对IP地址做限制，通常是伪造来源IP，绕过服务器端IP地址过滤，使非授权IP地址可以获取更多的防问权限。
攻击者可利用该漏洞访问受限系统，造成应用系统数据泄漏。
使用代理软件拦截请求包，修改HTTP头中的Host字段，伪造IP地址绕过限制。
综上，在代码中获取到的IP，很有可能是伪造的IP地址。服务端系统会根据获取到的IP地址，进行IP过滤或者权限控制，代码如下：
如果攻击者通过篡改X-Forwarded-For的IP地址，即可绕过IP禁用的限制。
1.使用getServerName()代替getHeader(“Host”)；
2.在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法Host header，或者在Apache和Nginx里指定一个ServerName名单；同时，Apache开启UseCanonicalName选项。
系统未检测当前时间用户是否已登录，未对同一用户同时在线数量限制。
3.若在多个浏览器上该账号可以同时登陆，则证明存在多点认证。
建议在不影响业务的前提下，重要业务系统禁止多点认证。当同一账号在另一地点登录时当前登录的账号应自动退出，并提示用户账户在其他地区正在登录，可能存在账号被盗的风险。
在用户进入登录界面时，但没有登录时，就已经产生了一个session，用户输入信息登录后，session的id不变，也就是说没有生成新session，原来的session也没有注销。攻击者事先访问系统并创建一个会话，诱使受害者使用此会话进行登录，然后攻击者再使用该会话访问系统即可对登录受害者的账户进行登陆。攻击的原理及流程如下图所示：
服务器与BOY建立了一个会话，比如sessionid为123456。
http://www.aaa.com/login.jsp?sessionid=123456，发给了受害者computer。
computer直接打开此链接，输入自己的用户名和密码登录系统。
http://www.aaa.com/viewprofile.jsp?sessionid=123456，
1.访问网站时，网站会设置cookie中的session
2.当用户等候后，cookie中的session保持不变
3.只要获取登陆前的session内容，就可以知道登陆后的session
攻击者可能会窃取或操纵客户会话和cookie，用于模仿合法用户，从而以该用户身份查看或变更用户记录以及执行事务。
2.登陆前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比，如果其值一样，则可判断其会话的cookies或者sessions未进行更新。
首先使用常规操作注册一个账号，作为待测试的用户账号。
构造 url： http://www.xxx.com/?PHPSESSID=你的sessionid
超长的字符串容易引起警觉，所以我直接改个短的。把 1 作为 sessionid
随后在攻击者浏览器把 session id 改为 1
1.不只形如 http://test/?XXXSESSIONID=1234 的链接可能存在这种问题，通过 POST 传递参数也同样存在这种问题。
2.对会话固定漏洞的挖掘不能局限于对形如 sessioniid 的变量的监控，应该着眼于一切有会话令牌性质的变量。（换句话说就是 sessionid 不只是 cookies 里那一点。）
3.会话固定与其定性为漏洞，不如定性为一个普通的攻击手法。
在用户提供的认证信息（例如用户名和密码）、相应的权限级别发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话，JAVA示例代码如下：
|
request.getSession().invalidate();//清空session
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期 ；
|
注意：这段代码需要在页面的最后部分加上才可以，否则将报错。
会话变量可控漏洞，会话中的参数可由客户端控制，导致客户端可以控制并修改会话参数。攻击者通过篡改会话变量，达到欺骗服务器的目的。
![失效的身份认证和会话管理]( "失效的身份认证和会话管理")
原文始发于微信公众号（LSCteam）：失效的身份认证和会话管理
评论