Most Common Security Issues Found in Login Functionalities

1. Home About Us Products Resources Career Blog Contact Us Email Us 10 Most Common Security Issues Found in Login Functionalities Home / Blog / Pentesting / 10 Most Common Security Issues Found in Login Functionalities  Harsh Bothra  10 June, 2021 What are you loo Search 10 Most Common Security Issues Found in Login Functionalities ALL CATEGORIES This blog discusses the common vulnerabilities or misconfigurations that a threat actor can exploit on login functionality & some remediations around it. Attack Surface Management Business CISOGuides News & Announcements Pentesting Press-Release Project Resonance Security Best Practices Security Risks Technology Tips Tool-Release During penetration testing and vulnerability assessment, the login functionalities are often encountered in some way or another. Most of the time, they are public-facing login portals where any user can attempt to log in to gain access to their accounts; on the other hand, sometimes, these login panels are restricted to specific users. The login functionality acts as a gateway that you need to unlock successfully to further access the application to its full potential. From a threat actor’s perspective, the login functionality is the main barrier to gain an initial foothold. Hence, it is essential from a penetration tester’s perspective to ensure that the login functionality implemented in the application is robust and secure against all types of vulnerabilities and misconfigurations. This blog will discuss the common vulnerabilities or misconfigurations that a threat actor can exploit on login functionality and some remediations around it. For this purpose, we will be following the mindmap as mentioned above: Vulnerability Test Cases LATEST POST Default Credentials 6 Reasons You Need to Manage Your External Attack Surface Often, on the admin panels, third party software integrations, etc., that come with a pair of default credentials are left as it is. This may allow an attacker to enumerate the third party service and look for its default credentials. These credentials are usually privileged admin users and may allow an attacker to gain a complete foothold in the application. Attack Surface Management – Risks of an Exposed Docker Image Default Credentials List: Credentials https://github.com/danielmiessler/SecLists/tree/master/Passwords/Default- Analysing Misconfigured Firebase Apps: A Tale of Unearthing Data Breaches (Wave 10) For example, an admin panel using default credentials such as “admin:admin” is easy to guess and may allow an attacker to gain access to the respective admin panel as the highest privileged user. Attack Surface Management – Risks of an Exposed Service / Port  Remediation: To remediate this issue, the developers need to ensure that the default credentials are disabled/changed and a strong pair of non-guessable credentials are enforced. User Enumeration OpenSSL v3: Two High- Priority Patches and A Week of Horror There are multiple scenarios where when a user provides an invalid username, the application responds with a verbose error message stating that the user doesn’t exist. There are other ways to identify this as well, such as: Error Message: Difference in the error message when a valid/invalid user name is provided. Timing Difference: Difference in server response timing when a valid/invalid user name is provided. Application-Specific Behaviour: In specific scenarios, there may be behaviour patterns that are specific to the application’s implemented login flow, and it may require additional observation to conclude if a user exists or not. BLOG ARCHIVES March 2023 November 2022 October 2022 September 2022 June 2022 May 2022 April 2022 March 2022 February 2022 January 2022 December 2021 November 2021 October 2021 September 2021 June 2021 May 2021 March 2021 February 2021 December 2020 November 2020 July 2020 June 2020 April 2020 May 2019 These issues may allow a threat actor to enumerate all the valid user’s of the application and further use them to perform targeted attacks such as brute-forcing and social engineering. Remediation: To remediate this issue, the developers need to implement proper handling so that the application doesn’t reveal any verbose error message on a valid/invalid username. Only a generic message is displayed. Similarly, the timing difference should not be significant enough to allow user enumeration. Missing Brute-Force Protection Most of the time, the login pages are accessible to the world, and the application allows any user to register and log in. In this chance, a user might have used a weak or guessable password increase. Suppose an application allows a user to attempt login irrespective of the failed attempts and fails to block the attempt. In that case, it may give a threat actor a window of opportunity to perform a brute-force attack and guess the password of the victim user.  Bypass Methods: Often the application implementation a rate limiting or captcha mechanism to restrict the brute-force attempts, however, there are multiple methods to bypass this implementation including but not limited to:  Using the various HTTP Request Headers such as below mentioned. You can find Top Headers in the from . dataset Project Resonance Wave 2 X-Originating-IP: 127.0.0.1 X-Forwarded-For: 127.0.0.1 X-Remote-IP: 127.0.0.1 X-Remote-Addr: 127.0.0.1 X-Client-IP: 127.0.0.1 X-Host: 127.0.0.1 X-Forwared-Host: 127.0.0.1 BLOG TAGS android apps attack surface attack surface management continuous security Using null bytes (%00) in the vulnerable parameters Sending the request without captcha parameter Adding fake parameters with the same “key”:”value” Limiting the threads or checking for race conditions Changing user-agents, cookies, and IP address Using IP rotation Burp Extensions to bypass IP based restrictions cve-2022-22965 cybersecurity Data breach dataleaks cyber data-leak Dependency Confusion Attack To test this issue, simply use Burp’s Intruder feature or any custom brute-force script with a password wordlist of 200 passwords having an actual password in the list. Suppose the application doesn’t restrict the invalid attempts and provides a successful response on a valid password. In that case, it is an indication that the application doesn’t implement any sort of brute-force protection. dns misconfigurations docker domain takeover easm entrepreneur exploit exposed risks exposed service featured internet-security firebase httploot internetsecurity kubernetes kubestalk linux management open port openssl osint opensource patch-management pentesting pii project-resonance Project Resonance secret security scanner spf records spring4shell threat-research vulnerability surface Remediation: To remediate this issue a developer may implement rate-limiting or CAPTCHA as an anti- automation mechanism.  Credentials Over Unencrypted Channel If the application accepts the credentials and logs in a user over an unencrypted communication channel, i.e. over HTTP protocol instead of HTTPS, the communication is vulnerable to man in the middle attack. An attacker may be able to sniff in the network and steal sensitive information. Remediation: To remediate this issue, the developers need to strictly enforce HTTPS so that the application doesn’t communicate over HTTP. As a best practice, the developers should implement HSTS headers across all the subdomains as well. Additionally, implementing Secure Flag on the session cookies that were fetched after login over HTTPS, ensures that the cookies are not stolen over the unencrypted channel. The secure flag protects cookies to be stolen over an unencrypted channel or via attacks like man-in-the-middle attack. Cross-Site Scripting The login pages may also be vulnerable to cross-site scripting under multiple scenarios. However, these are generally authenticated but can still be used to perform malicious actions such as redirecting a user to an attacker-controlled website and social engineering them to get hold of their credentials. Let’s assume an application having a login page reflects the invalid username in the error message. This username is also present in the URL like: attempt to execute a reflected type of cross-site scripting in the user parameter by sending a malicious javascript payload.  www.something.com/login/?user=harsh ; now, an attacker may Remediation: To remediate this issue the developers can implement a proper input validation and sanitising on the input fields and not reflect user-supplied input in the error messages. Additionally, implementing a HTTPOnly flag on the session cookies can protect sensitive cookies from being stolen using scripting attacks. Parameter Pollution & Mass Assignment A simple security misconfiguration may allow an attacker to bypass the authentication and gain unauthorised access to the victim user’s account. In this attack scenario, an attacker may attempt to bind multiple values to the same key or define various key-value pairs, i.e. using multiple usernames in username parameters or using multiple username parameters themselves. The way a server processes this may allow an attacker to access another user’s account. Remediation: To remediate this issue, the developers need to ensure that the application discards the use of multiple key-value pairs and only accepts one at a time to avoid this attack. Also, developers would need to check if any additional parameter is added to the original request and discard all the additional parameters, accepting the originally supplied parameters only.  SQL/NoSQL/LDAP/XML Injection This is one of the most common attacks that comes to one’s mind when we talk about login functionality. Based on the implementation used in the login functionality, an attacker may attempt to bypass it by injecting SQL/NoSQL/LDAP/XML injection payloads and gain access to the victim’s account. Remediation: To remediate this issue, the developers must ensure that the user-supplied input is validated correctly and security best practices for implementing database queries are followed. You can find a detailed guide at: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html Sensitive Information Disclosure While performing a login action, it is often observed that some applications store the credentials in response or the javascript files. An attacker may attempt to identify a way to extract the credentials from the response or javascript files. Also, in some cases, the application access may show additional information that may belong to other users or the application server itself and may help further exploitation. Remediation: To remediate this issue, the developers must ensure that the application doesn’t cache or store sensitive information such as credentials in an insecure place such as server response or javascript files. Response Manipulation Often, it is observed that the application returns “success”:false or “success”:true or similar responses when an invalid vs a valid set of credentials is supplied. However, if the application is not performing the server-side validation properly, it is possible to manipulate the response; for example, changing the “success”:false to “success”:true may allow an attacker to gain unauthorised access to the victim’s access account. This attack mainly results in success where the authentication token or cookie generation logic lies at the client-side, which is a bad practice. Similarly, in many scenarios, the application also uses different response status codes such as 403, 200, etc. It is possible to change the status code from 403 to 200 to bypass the restriction and attempt to gain successful access to the victim’s account. Remediation: To remediate this issue, the developers need to make sure that the server-side validation is in place and any attempts of client-side manipulation are discarded. Authentication Bypass In certain situations, it is impossible to bypass the authentication directly. Still, it is possible to access some specific endpoints or pages by directly navigating to them or in any other way possible. This allows an attacker to bypass the restrictions of required authentication and allows an unauthorised attacker to access those functionalities. For Example: An unauthenticated attacker performs a directory enumeration and identifies an endpoint /goto/administrator/ which is directly accessible to him without any restrictions. Remediation: To remediate this issue, developers would be required to ensure that all the authenticated endpoints are adequately placed behind the authentication and a proper authorisation check is implemented. Bonus: Cross-Site Request Forgery (with a twist) Usually, most applications are vulnerable to log in based CSRF issues, but there is no security impact in general. Thats’s what you are thinking, right? However, when an application utilizes the Single Sign-On method, the login CSRF comes in handy. This may allow an attacker to connect the victim user’s account to an attacker-controlled entity and can further be used to steal sensitive information or perform malicious actions.  Example Report: https://hackerone.com/reports/171398 Remediation:  To remediate this issue, the developers must ensure that the state parameter is implemented and appropriately validated. Apart from the above-mentioned vulnerabilities in the login page, several other vulnerabilities arise when third party integrations are used for authentication such as SAML, OAuth2.0 or other third party services. However, these authentication mechanisms are themselves a vast topic to understand and explore. We will soon be coming up with a separate series on Single Sign On (SSO) and JWT related attack vectors.  Pentesting  Security Best Practices Previous: The Cybersecurity Guide for an Entrepreneur Next: 9 Cybersecurity Tips for Remote Working RESEARCH COMPANY DOWNLOADS REGISTERED OFFICE  102 First Floor, 60, Grays Inn Road, London, United Kingdom, WC1X 8AQ Blog About Us Privacy Policy DROP AN EMAIL  Code Leak Search Engine Media Kit Terms & Conditions info@redhuntlabs.com Project Resonance Events Calender Compliance Policy CALL US  +(91) 9971 658929 Talks And Presentations Community Support Sample Report BOOK MEETING  /calendly We value your privacy We use cookies to enhance your browsing experience, serve personalized ads or content, and analyze our traffic. By clicking "Accept All", you consent to our use of cookies. Request Free Trial Schedule Meeting Customize Reject All Accept All Copyright © 2023 Redhunt Labs . ALL RIGHTS RESERVED. Developed By : Dreamsdesign.in