Top 10 most important Web security risks 3-A3-Incorrect authentication and session management

OWASP top 10 top 3rd threats: "corrupted authentication and session management". In short, attackers can obtain the sessionID By eavesdropping the user name and password when accessing HTTP, or by session, then impersonate the user's Http access process.
Because HTTP itself is stateless, that is to say, each HTTP access request carries a personal credential, and SessionID is used to track the status, sessionID itself is easily listened to on the network, so attackers often listen to sessionID for further attacks.
These vulnerabilities often exist in "change my password", "remember my password", "forgot password", "security question", "logout login", and "email address" on the web page".
In general, how can we prevent such vulnerabilities?
First, we need to review our architecture as a whole
L The authentication mechanism must be simple, centralized, and standardized;
L use the standard session id provided to us by the container;
L ensure that SSL is used to protect our passwords and session IDs at any time
Second, verify the authentication Implementation Mechanism
L check the implementation method of SSL
L verify all authentication-related functions
L ensure that all sessions can be closed by the logout action
L use OWASP's WebScrab to test your application
How to perform a verification test the so-called authentication is to establish a process of believing that something or someone is real. The authentication comes from the Greek α-θ ε Tau-ε κ ς, that is, true, trusted. Authentication itself depends on multiple authentication factors. In the computer security field, authentication means to verify the digital identity of the communications initiator. A common authentication process is user login authentication, the so-called authentication test is to understand the authentication mechanism in the system and find a way to bypass the authentication mechanism.
There are many considerations for certification testing. We will explain them one by one.
LPass the password on the encrypted channel
In principle, user authentication must be transmitted through an encrypted channel. Our purpose here is not to verify whether, for example, HTTPS is secure. What we need to verify is whether the user's authentication information has been encrypted.
When a user logs on, the most common method is to transmit the user name and password through the POST method. Generally, the authentication information is transmitted through insecure HTTP, or encrypted HTTPS transmission. We have noticed that some websites even display HTTPS to us on the login page, but in fact they still use HTTP. The simplest way is to use the network listening tool, for example, SnifferPro or Ethereal is used to determine whether the data is encrypted.
Below, we use the WebScrab of OWASP to take some information for example.
Assume that the user is required to enter the user name and password on the logon page, and then there is a "Submit" button. In WebScrab, we get the following request data:
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: 1.8.1.14) Gecko/20080404
Accept: text/xml, application/xml, application/xhtml + xml
Accept-Language: it-it, it; q = 0.8, en-us; q = 0.5, en; q = 0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1, UTF-8; q = 0.7, *; q = 0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID = LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64
Delegated_service = 218 & User = test & Pass = test & Submit = SUBMIT
In the above data, we can see that the POST method sends data to the ingress through the HTTP protocol.
Let's look at the next example. If the HTTPS protocol is used, the request header data is as follows:
POST https://www.example.com: 443/cgi-bin/login. cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: 1.8.1.14) Gecko/20080404
Accept: text/xml, application/xml, application/xhtml + xml, text/html
Accept-Language: it-it, it; q = 0.8, en-us; q = 0.5, en; q = 0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1, UTF-8; q = 0.7, *; q = 0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language = English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50
Command = Login & User = test & Pass = test
It can be seen that the data in the above example is encrypted and transmitted to the https://www.example.com: 443/cgi-bin/login. cgi, which ensures that the data is encrypted and not stolen by others.
Let's look at the example below. We can send data over HTTPS on a page that can be accessed through HTTP.
POST https://www.example.com: 443/login. do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: 1.8.1.14) Gecko/20080404
Accept: text/xml, application/xml, application/xhtml + xml, text/html
Accept-Language: it-it, it; q = 0.8, en-us; q = 0.5, en; q = 0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1, UTF-8; q = 0.7, *; q = 0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID = s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45
User = test & Pass = test & portal = ExamplePortal
As shown above, our request leads to https://www.example.com via HTTPS: 443/login. do, but if we look at the Referer value again, we find that we are from the HTTP page http://www.bkjia.com/homepage. do. In this case, our browser window does not tell us the current secure connection, but in fact we are using a secure connection.
In the above example, if we use the Get method, the entered user name and password will be displayed in plaintext in the URL, which is obviously not desirable. So, if it is feasible to transmit data through HTTPS through the Get method, let's look at the following data
GET https://www.example.com/success.html? User = test & pass = test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: 1.8.1.14) Gecko/20080404
Accept: text/xml, application/xml, application/xhtml + xml, text/html
Accept-Language: it-it, it; q = 0.8, en-us; q = 0.5, en; q = 0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1, UTF-8; q = 0.7, *; q = 0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
From the above example, we can see that both the user name and password exist in the URL in plain text, unlike the previous examples in the message body, but it does not mean that attackers can easily see this information. TLS/SSL is a highly secure protocol after all, and the entire HTTP packet is encrypted, however, note that these user names and passwords are stored on the proxy and server during transmission, which may expose user information.
User Enumeration Test Method
In short, this test attempts to obtain correct user names through interaction with the application's authentication mechanism, which is very effective for the brute-force cracking we will discuss later, once you confirm the correct username, you can use brute force password cracking to try the password.
In general, WEB applications may provide some information feedback for correct user name input. For example, if we enter the wrong password, sometimes the feedback will inform us that the system has the user or the password is incorrect. Therefore, as a tester, we need to try different requests to determine whether the system will return different results.
Test the HTTP Response Message:
Enter the correct user name and password
Expected results: Use WebScrab to capture the server's returned information (HTTP 200 Response, message length)
Enter the correct username/wrong password
Expected results: the following results are often returned from the browser:
Or return the following
Even the following response
Login for User foo: invalid password
Enter a user name that does not exist
Expected results: the returned results may be as follows:
Or the following message
Login failed for User foo: invalid Account
Generally, for different error messages, the server often returns the same message. However, if they are different, the tester should try to see the following situations:
Customer request: Correct user/wrong password --> server return: Wrong Password
Customer request: Wrong user/wrong password --> server return: user does not exist.
Obviously, the first one tells us that we entered the correct user name. In this way, we can obtain some correct user name information.
There are other methods to list:
Some applications return specific error information;
Analyze URL and redirect URL
URL:
Http://www.foo.com/err.jsp? User = baduser & Error = 0
Http://www.foo.com/err.jsp? User = gooduser & Error = 2
The above two URLs tell us the Error page, but the previous one is the Error value 0, and the next Error value is 2, so we can guess that we have obtained a correct user name.
URI Detection
Sometimes, when a Web server receives a directory access request, it returns different information based on whether the directory exists. For example, in some websites, a directory is set for each user, if we try to access an existing directory, it may return the following page:
403 Forbidden error code
404 Not found error code
Example:
Http://www.foo.com/account1-error message returned: 403 Forbidden
Error message returned at http://www.foo.com/account2-: 404 file Not Found
Obviously, account1 actually exists.
LTesting User Account
As we all know, there are often default accounts or common accounts that are easy to guess in the system, and many users often use the default password. Similarly, R & D personnel of some application system test accounts sometimes forget to delete them. This is actually a vulnerability, which is often caused by the following reasons:
Inexperienced IT engineers often do not change the default password of installed architecture components;
Programmers leave backdoors in the application for testing, but forget to delete them at release;
System Administrators and Users use simple passwords;
The system has embedded internal usernames and passwords that cannot be deleted
......
For injection into Cisco routers or WebLogic, they all have some default user names and passwords. We can try them directly. For some applications that we do not know at all, we can try the following:
Try the following common system administrator accounts: "admin", "administrator", "root", "system", "guest", "operator", "super", "qa ", "test", "test1", "testing", you can also try combinations of user names and passwords, such as "password", "pass123", "password123", "admin ", or guest. If none of the above works, we can write some scripts to try a combination of similar usernames and passwords.
The Administrator's password is sometimes related to the system name. For example, if the application system we tested is called "Obscurity", you can try the combination of user name and password Obscurity/obscurity.
On the registration page, we can also guess the format and length of the user name and password.
Try all the usernames and empty passwords mentioned above.
View the source file on the page and find all the information that references the username and password, for example, "If username = 'admin' then starturl =/admin. asp else/index. asp"
Find the username and password information that may be contained in the comments in the source file;
.......
LStrong testing (brute-force testing)
The effects of using any technology in different people are different, just as brute-force testing is also called brute-force cracking, security Service personnel and testers use this technology to verify the existence of vulnerabilities, while attackers use it to find vulnerabilities.
Web application systems usually have some user authentication methods, such as certificates, fingerprints, and one-time tokens. However, they are often a combination of user names and passwords, this makes brute-force cracking possible.
When conducting a brute-force test on a Web application system, we need to first understand the system authentication mechanism. Generally, the Web system uses the following two mechanisms:
HTTP Authentication: includes basic access authentication and digital access authentication.
HTML form-based authentication.
We will give a brief introduction to these authentication methods:
Basic access authentication
Basic access authentication assumes that the user will use a combination of the user name and password to indicate his/her identity. When the user's browser uses this mechanism to access the site, the web server returns a 401 response containing the "WWW-Authenticate" header, containing a "Basic" value, and protected domain name (for example, WWW-Authenticate: basic realm = "wwwProtectedSite") a prompt box is displayed for the user to enter the domain user name and password. Then, the client browser returns a response to the server, which contains the "Authorization" header, "Basic" value, and the 64-bit encoding that connects the user name, colon, and password (for example, authorization: Basic b3dhc3A6cGFzc3dvcmQ =), but unfortunately, this response is easily decoded as long as it is listened to by attackers.
Let's take a look at this process:
1. The client sends a standard HTTP Request
GET/members/docs/fileloud HTTP/1.1
Host: target
2. The web server locates the accessed resource in a protected directory;
3. the server sends an HTTP 401 authentication request;
HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm = "User Realm"
Content-Length: 401
Keep-Alive: timeout = 15, max = 100
Connection: Keep-Alive
Content-Type: text/html; charset = iso-8859-1
4. A data window is displayed in the browser that requires the user name and password to be entered;
5. the user enters the user name and password, including the following data, and then submits it again;
GET/members/docs/fileloud HTTP/1.1
Host: target
Authorization: Basic b3dhc3A6cGFzc3dvcmQ =
6. The server compares the customer information with the stored information;
7. If the authentication is correct, the server sends back the requested content. If the request fails, the server returns the HTTP