Shulou(Shulou.com)05/31 Report--

This article shows you the Web login authentication class vulnerability analysis, defense summary and security verification mechanism design example analysis, the content is concise and easy to understand, absolutely can make your eyes bright, through the detailed introduction of this article, I hope you can get something.

In the aspect of web login authentication, from the sub-function, it can be divided into login frame login, forgetting password (password reset), changing password, verification code, sending mobile phone verification code, sending mailbox verification code, registered account number, login information error prompt, account locking and other small functions (single sign-on will also talk about principle, this article will not cover) The login of each web site consists of about all or part of the above gadgets (here the vulnerabilities are divided by these gadgets, and the vulnerabilities are more targeted and comprehensive, but there is still no way to avoid crossover).

Start with the most basic and common list:

Login box

Login box account password server persistence: when you open the login page and find that the account password has been filled in, click login to go directly to the backstage

Repair solution: the logic of saving account password processing is local, and session is destroyed in time.

Information disclosure: the login box provides a sample user name, such as sample mailbox, mobile phone, and user name rules that cause hackers to master the rules and generate dictionaries

Fix: do not display the sample user name

Sql injection: there is sql injection in the user name field or password field, which is typical of universal password login (as we all know)

Fix: use parameter binding to query and precompile statements, if you use various frameworks to program in accordance with the requirements of framework security development

XSS: there is a XSS in the username or password field. Typically, the reflection XSS hits itself.

Repair plan: use a variety of XSS filter library coding library, please Baidu for details, this article is not a XSS topic

Account password brute force cracking: hackers keep trying to log in through tools or scripts to load account password dictionaries

Fix: add CAPTCHA (incorrect CAPTCHA may lead to bypass, etc., which may not be prevented, as described below)

User enumeration: the incorrect user name indicates that the password does not exist, and the correct user name indicates that the password is incorrect, thus enumerating the user name

Fix: use vague error prompts, such as incorrect username or password

Account locking: when the user explodes, there are too many errors to lock the account, and then hackers try to use user names in batches, resulting in most user names being locked.

Account details leaked: submit a valid user name, and the server returns the account, identity, password and other details related to the user name.

Repair scheme: use CAPTCHA to prevent blasting, try not to use too many logins to lock, or set short-term locking

Low-frequency impact blasting: using scripts to keep blasting at slow frequency, a defense strategy with large numbers of limited frequency

Fix: use CAPTCHA mechanism

Picture verification code

Easy to identify: there are too few or no miscellaneous points in the verification code, so that the content of the verification code can be identified by the program.

CAPTCHA front-end generation: CAPTCHA is made with js, and random characters are filled in the front-end dom with js generation point.

Separate verification: the verification code and the parameters to be verified are not in the same http request, resulting in an attack after successful verification, such as brute force cracking the request to catch the current user name and password after the verification code is successful

Empty: when the value or parameter of the CAPTCHA is left empty, it can be verified directly. This is because the server logic judgment lacks a CAPTCHA to be empty.

CAPTCHA reuse: the same CAPTCHA can be used for an unlimited number of times, or the CAPTCHA can be used up or not destroyed, resulting in blasting or arbitrary registration.

Front-end display: the verification code generated by the server is not a picture, but the string is returned directly to the front-end.

Arbitrary value: if the http request is intercepted, any value of the CAPTCHA can be verified by the CAPTCHA.

Low priority: the verification code is not the first to verify after the same http request to the server, such as verifying the user name first, causing users to enumerate

Coding platform: use the coding platform to call CAPTCHA API to obtain CAPTCHA for identification, and return CAPTCHA

Repair scheme: the verification code must be generated on the server side to add noise interference and distorted enough to return to the front end in the image format, and the front end is sent to the server with the verification code and the verification parameters need to be sent in a request. The first priority of the server verifies the existence and correctness of the verification code, and a verification code is used once and then destroyed.

Mobile phone and mailbox verification code

Front-end display: the verification code generated by the server is returned to the front-end of the page, resulting in the leakage of verification information.

Low complexity: a 4-digit CAPTCHA that can be enumerated for login or registration if there is no limit on the number of times on the server

Zha_ egg: constantly send text messages or emails to verify the mobile phone number or mailbox through scripts, causing the receiver to accept a lot of spam messages.

Account locking: if a single mobile phone or mailbox locks more than a certain number of times for a certain period of time, automatically lock the account in batches

Mismatch: like requesting that the user name and phone do not match but still send the CAPTCHA, resulting in sending text messages to any number.

Tariff consumption: there is a limit on the number of times of a single mobile phone number, using a large number of different mobile phone numbers to send tens of thousands of text messages in a short time.

Fix: the verification code must have a certain complexity, at least 6 digits, and cannot be returned to the front end. Based on the limit of the number of times based on the client session, make an appropriate locking strategy, and compare whether the account and the bound mobile mailbox match.

Forget the password.

Account enumeration: after you enter the user name and submit it, the system prompts the user that the user does not exist, etc.

Authentication tampering: enter a valid user name and then enter another mailbox or mobile phone to accept the verification code

Password reset

CAPTCHA bypass: the picture CAPTCHA or mobile CAPTCHA and the reset account are not in the same request or bypassed by the techniques in this article

User enumeration: determine whether a user exists by resetting the interface and get the user name

Any account reset: the system resets the password through the user name and password parameters, resulting in the password of any account can be reset

Authentication tampering: enter a legitimate user name and use the hacker's mailbox or mobile phone to receive the password reset by the system

Repair scheme: judge the legal relationship between the account and the binding verification method, include a CAPTCHA mechanism in important requests, and use fuzzy error messages for accounts that do not exist or are incorrect.

Arbitrary registration

User enumeration: when registering, the system prompts the user name to be registered, and enumerates users in bulk

CAPTCHA bypass: after using the correct image CAPTCHA or mobile email CAPTCHA, submit the registration information. For other ways of bypass, please see above.

Sql injection: the registration field is not bound with precompiled parameters, resulting in injection

Mobile CAPTCHA burst: the CAPTCHA of mobile phone or mailbox is too short to be strong and violently cracked.

Fix: submit the verification code and registration information in the same request, and the server first verifies whether the verification code is correct. For the verification code mechanism, see above.

Combined bypass

Through the various security bypass techniques mentioned above, we can try one or more means to bypass CAPTCHA code, mobile phone verification, and so on. There will always be a variety of small loopholes that are combined to be bypassed and attacked, depending on what defensive measures are used in the authentication mechanism, such as whether to use picture CAPTCHA, mobile CAPTCHA, user enumeration, and so on.

Secure authentication mechanism

In the above, with so many attacks on authentication, what kind of authentication mechanism is secure? With so many replay attacks above, what is the most effective way to combat replay attacks?

For those who can use scripts or programs to automate attacks, the most effective defense is CAPTCHA!

What are the key points of defense?

How to avoid loopholes that can be bypassed by logic as much as possible? It is best to reduce the artificial stone steps, or even put all the parameters that need to be authenticated in a http request!

For parameter filtering, you can use regular matching to use regular matching, such as mailbox, mobile phone, and * * to use regular verification, which can completely avoid sql injection into XSS.

For those that cannot use regular matching, use an organization's open source filter library such as owasp to prevent XSS for parameters.

For the parameters of the same http request, the CAPTCHA has the highest priority verification. When verifying the CAPTCHA, it is necessary to verify the existence of the CAPTCHA, the existence of the parameters and the one-time verification.

Try not to use interfaces, because interfaces generally cannot use CAPTCHA

Return information to the front end, using the principle of minimum information, and return only the necessary information

Design of a secure Authentication Mechanism

Login function: put the user name and password and other required fields (such as verification code, verification code only once, and enough miscellaneous points and complexity) to the front end for the customer to fill in together, and then put the same http request to submit to the back end. The back end judges whether there are verification code parameters, and then determines whether the verification code is correct, and then regularizes some fields, which cannot filter and transcode the parameters regularly. Then use parameter binding and precompilation to query the database, error or non-existent prompt front-end user name or password error, so as to prevent automation attacks and SQL injection information disclosure and so on.

Password reset function: put the verification code, user name, authentication factor (mailbox, mobile phone, etc.) into the same http request, first verify the existence, correctness and one-off of the verification code, then verify the regular format of the parameters, filter the coding of the unverifiable parameters, verify the matching of the user name and authentication factor, and finally trigger the relevant functions.

In the above two cases, even if the attacker wants to hit the library, lock the account, batch reset and other operations, it will only affect the single-digit account because of the verification code, which has little impact on the system as a whole.

Other functions are the same, to be combined with the actual scene design, you can control the risk to a minimum!

The above content is the Web login authentication vulnerability analysis, defense summary and security authentication mechanism design example analysis, have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.