▒█████ █████▒ █████▒ ██████ ▓█████ ▄████▄ ██▒ █▓ ▄▄▄ █ ██ ██▓ ▄▄▄█████▓ ▒██▒ ██▒▓██ ▒▓██ ▒▒██ ▒ ▓█ ▀ ▒██▀ ▀█▓██░ █▒▒████▄ ██ ▓██▒▓██▒ ▓ ██▒ ▓▒ ▒██░ ██▒▒████ ░▒████ ░░ ▓██▄ ▒███ ▒▓█ ▄▓██ █▒░▒██ ▀█▄ ▓██ ▒██░▒██░ ▒ ▓██░ ▒░ ▒██ ██░░▓█▒ ░░▓█▒ ░ ▒ ██▒▒▓█ ▄ ▒▓▓▄ ▄██▒▒██ █░░░██▄▄▄▄██ ▓▓█ ░██░▒██░ ░ ▓██▓ ░ ░ ████▓▒░░▒█░ ░▒█░ ▒██████▒▒░▒████▒▒ ▓███▀ ░ ▒▀█░ ▓█ ▓██▒▒▒█████▓ ░██████▒▒██▒ ░ ░ ▒░▒░▒░ ▒ ░ ▒ ░ ▒ ▒▓▒ ▒ ░░░ ▒░ ░░ ░▒ ▒ ░ ░ ▐░ ▒▒ ▓▒█░░▒▓▒ ▒ ▒ ░ ▒░▓ ░▒ ░░ ░ ▒ ▒░ ░ ░ ░ ░▒ ░ ░ ░ ░ ░ ░ ▒ ░ ░░ ▒ ▒▒ ░░░▒░ ░ ░ ░ ░ ▒ ░ ░ ░ ░ ░ ▒ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░░ ░ ▒ ░░░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░░ ░ ░ ░ ░ ░ ░ ░ ░ ░
06.authentication and authorization
>>> portswigger: https://portswigger.net/web-security/authentication is the process of determining whether someone is really who they claim to be. for example, webapps often rely on username & password pair for this. authentication factor represent something the user owns, know, or is. authentication factors: something the user has / something the user knows / something the user is. single factor, means that the user only need to provide one of the 3 factors we saw. typical single factor is the user to provide the password. two factor, MFA. requires a user to provide two or more of the three authentication factors. sample, the ATM machine, you will need to provide two factors, something you have: the credit card and something you know, the pin. if a password does not adhere to a strong password policy, it is exposed to attacks such as: -dictionary attack | can be language oriented, role oriented, etc. | the goal is to guess passwords by selecting words from the dictionary. -brute-force attack | tries to use every possible combination of characters to guess the password. takes time, will be good to use this attack only if the dictionary attack did not work. number of attempts depends upon the character domain and password length (charset) sample: if the character domain is [a-zA-Z0-9] and the password length is 8, the max numbers of attempts will be 62^8. common wordlists: http://www.openwall.com/wordlists/ https://github.com/danielmiessler/SecLists https://wiki.skullsecurity.org/Passwords -STRONG PASSWORD POLICY ==> length: at least 10 characters ==> never use the same password twice ==> composition (at least one uppercase char / one lower / one digit / special character) ==> do not include personal information and dictionary words ==> change password regularly (monthly, annually) -STORING HASHES from server-side perspective, passwords must never be stored in clear text. passwords need to be hashed (preferably with a salt) before they are stored. -LOCKOUT/BLOCKING REQUESTS to avoid brute force and dictionaty attacks, system can be designed to block the access. typical example of good system design: -* adds and incrementing delay after each failed login attempt -* after 3 failed attempts show a CAPTCHA puzzle -* after 10 failed attempts, locks the user for a certain amount of time. -USER ENUMERATION authentication mechanics accept a user identifier and a secret word (pass), know by only the user. badly designed system can reveal sensitive information about the existence of a user. example, an app can reveal the existence of a user. determinig valid usernames is something not considered serious threat, users are half of what is needed. samples: enumerate via error messages -login for user foo: invalid password -login failed, invalid user ID -login failed, account disabled -login failed, this user is not active handle exception ? -login failed; invalid user ID or password ... USER ENUMERATION VIA WEBSITE BEHAVIOR some apps may not display the previous messages but have a distinct behavior on user existence. if that behavior is identified, it can be attacked via user enumeration. samples: user does not exist: cookies are deleted / user goes to a known fixed page / the HTML is fixed user exists: cookies are not deleted or a new cookie is set / user goes to a user-specific page / the HTML changes or is different from an invalid-user ....USER ENUMERATION VIA TIMING ATTACKS there will be two most common behaviors, -user does not exist in the DB: show error + abort -user exists in the DB: retrieve user, calculate password, check if the password matches. because of this, it may possible to perform user enumeration by timing how long it takes to the applicaton to send a response. this can be exploited and allow and attacker to discover whether a user is present on the system. ADVANTAGE OF USER ENUMERATION once this info is available to the attacker, it can be performed any attack requiring the username component: - a dictionary (or brute force) attack agains the password to discover the user's password - a password reset for that user if the system suffers from a weakness in the password reset feature. in order to perform user enumeration, a login page should return different messages based on the submittal of a pair of: (asumming we dont know the password) -correct username / wrong password -wrong username / wrong password now that it is needed to check for differences, "burp comparer" can be used to compare responses. ... REMEMBER FUNCTIONALITY after a successful authentication, the web app does not ask the user to log in(usually for a period of time). this function can be implemented through the following methods: -through the browser cache -by storing credentials permanently within the web storage -by storing the credentials within a cookie password inputs or any sensitive information, must not be cached. if yes, an attacker can steal info from there. the cache method relies on HTML, the following code enable the browser to cache the password: INPUT TYPE="password" AUTOCOMPLETE="on" cookie method makes use of cookies to store credentials. alternatively, a token might be stored in the cookie, better feature due to the expiration, shorter than the users password. concerns: attackers can steal the cookie through the following attacks -XSS attack, only if the cookie has not been marked with the flag HTTPOnly. -Session Hijacking, via packer sniffing only if the cookie is sent over an unencrypted channel. web storage method, could be local storage to store credentials. a developer can use the API call localStorage.setItem() to add an item containing credential data to local web storage. web storage is a data container accessible and writable by all pages sharing the same origin, therefore, an attacker could access web storage after a successfull XSS attack. if password has been stored unencrypted, the attacker could obtain the victim's password. best defensive techniques > cache browser method defense autocomplete HTML attribute instructs the browser on whether storing certain form information is allowed or not. the following code can be used to disable the cache for the HTML password element. > cookie method defense any sensitive information like password must be encrypted before storing it within the cookie. if "remember me" cookie is stolen, an attacker can impersonate the victim without knowing the actual password. > web storage method defense any sensitive information like password must be encrypted before storing it. > PASSWORD RESET FEATURE generally, it is implemented by sending an email to the user with a new pass or a link to trigger the password reset function. at a first step, web app could ask one or more secret questions before sending the email. > easily guessable answers secret questions are a critical component. they are just like "another password" and they are usually the weakest link in the authentication system. it is unique by each user, however, some sites provide sometime suggestions that can represent vulnerabilities. to avoid dictionary or brute force attacks, the web application must limit the answer attempts and then block the requests coming from a malicious user. easily implemented by counting a user's incorrect attempts and blocking the IP after several consecurity tries. IP can always be changed by the attacker through proxies or TOR. attacker could easily guess the answer of a question if: -its response has a public answer. --> how many people live in Rome ? -its response has a private answer but is easily guessable (social engineering) --> whats your mother's name ? -its response has a limited domain --> which country do you prefer ? web app, should never allow unlimited attempts to answer a secret question. > PASSWORD RESET LINK normally, this protocol requires the user to click a link, usually an email to trigger the password reset. weaknesses: -guessable, password reset link -predictable password reset token -recyclable password reset link best practice -link should contain a token --> minimum length N characters: N>6 --> wide character set: for example, [A-Za-z0-9] --> purely random and unpredictable --> subject to expiration soon: 30 or 60 min the link triggering the password reset does not contain a random token, and it is easily guessable, it contains only a reference to the user requuesting the password reset action. this can be easily created by an attacker and used to reset the password of arbitrary users. guessable password reset link: elsfooradio/reset.php?user=els@fooradio.com for this one, it is a simple one, as attacker the only need is the email. recycable password reset link: this link types can be used more than once. if an attacker obtains it, he can reset the victims password even if the link has been already used.