Analysis of authentication and session management of website invalidation

In general, web developers are aware of regular web security vulnerabilities during development. But there are also some dangerous and obscure vulnerabilities that are widely present in Web applications. Most developers do not take any account of these vulnerabilities, leaving the Web application still in jeopardy. Failure authentication and session management is one such vulnerability. According to the latest owasp top 10, it ranks third in the 10-strong web vulnerability. This means that it is a highly dangerous vulnerability that exists in applications on most Web sites on the Internet.

Identity authentication and Session management

Before we explain this dangerous vulnerability further, let's take a look at the basics of identity authentication and session management. Identity authentication, the most common is the login function, often is the submission of user name and password, in the case of higher security requirements, have to prevent password brute force to crack the verification code, based on the client's certificate, physical password card and so on. Session management, HTTP itself is stateless, using session management mechanism to achieve connection recognition. The result of identity authentication is often to obtain a token, usually placed in a cookie, and then identify the identity of the user according to the authorized token, and do not need to log in every time.

What is invalid identity authentication and session management?

User identity authentication and session management are the most critical processes in an application, and flawed design can severely disrupt the process. When developing Web applications, developers tend to focus only on the functionality required by the Web application. For this reason, developers typically build custom authentication and session management scenarios. But it's hard to implement these scenarios correctly, as a result these custom scenarios often have vulnerabilities: exit, password management, timeout, remember me, secret issues, account updates, and so on. Because each implementation is different, it can sometimes be difficult to find these vulnerabilities.

Some examples of this vulnerability exist:

1, users do not authenticate users before changing the password, but rely on the IP address of the session;

2, no session timeout limit;

3, the user forgets the password, the password retrieve function is too simple.

Example 1: Improper application timeout settings. Users use public computers to access Web sites. When you leave, the user does not click Exit, but directly closes the browser. An attacker can authenticate with the same browser after one hours.

Example 2: The ticket booking application supports URL rewriting and puts the session ID in the URL: http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest =hawaii

A certified user of the site wants his friend to know about the ticket discount. He emailed the link above to his friends, unaware that he had leaked his session ID. When his friends use the link above, they will use his session and credit card.

Example 3: An internal or external attacker enters the system's password database. The user's password stored in the database is not encrypted and all user passwords are obtained by the attacker.

How do I verify that the program has failed authentication and session management?

The data that most needs to be protected is the authentication voucher (credentials) and session ID.

1. Do you always use hashing or encryption protection when storing authentication credentials?

2. Whether the certification voucher can be guessed, or can be through weak account management function

(For example, account creation, password modification, password recovery, weak session ID) rewrite?

3. Is the session ID exposed to the URL (for example, url rewriting)?

4. Is session ID vulnerable to session fixation?

5. Does the session ID timeout? Can users quit?

6. Does the session ID rotate after successful registration?

7. Are passwords, session IDs, and other authenticated credentials only transmitted over TLS connections?

How to prevent:

1. Distinguish between public areas and restricted areas

The public area of the site allows anonymous access by any user. Restricted zones can only accept access by a specific user, and users must authenticate through the site. Consider a typical retail website. You can browse the product categories anonymously. When you add items to your shopping cart, your application uses the session identifier to verify your identity. Finally, when you place an order, you can perform a secure transaction. This requires you to log in to authenticate the transaction over SSL.

Dividing sites into public and restricted access zones allows you to restrict the use of SSL by using different authentication and authorization rules in different areas of the site. Using SSL can cause performance degradation, and in order to avoid unnecessary overhead, when designing a site, you should restrict the use of SSL in the zone that requires authentication access.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/web/Skills/