Attack Java Web applications [2]

Note: This section is intended to help you understand the interaction process between the client and the server. I personally do not like xss, so I have little knowledge about xss, so I can only briefly explain it. This section mainly includes HttpServletRequest, HttpServletResponse, session, cookie, HttpOnly, and xss. The article is written a few days ago and should have a sequel, but there is no time to continue writing in years. My work is not in the security industry, so I am not professional and hope you can understand it. Later sections may include SQL Injection in Java, Servlet container-related, Java framework issues, and eclipse code auditing.

 

0x00 Request & Response (Request and Response)

There is no language for requests and responses in Web development, whether it is ASP, PHP, ASPX or JAVAEE. The core of Web services should be the same.

In my opinion, the core and most basic aspects of Web development are Request and Response! In the end, our Web applications are user-oriented, and requests and responses allow interaction between the client and the server.

The server mainly focuses on client requests and responses.

For example, after intercepting a request through Tamper data, we can clearly see from the request header that the client request address sending the request is localhost.

The browser is FireFox, and the operating system is Win7. These are the Request behaviors of the client, that is, requests. Zookeeper

After the client sends an Http request to the server, the server will receive the request information submitted by the client (HttpServletRequest), process it, and return the processing result (HttpServletResopnse ).

Demonstrate the information contained in the request header received by the server from the client: zookeeper

The following content is output on the zookeeper page:


host=localhost
user-agent=Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0
accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language=zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
accept-encoding=gzip, deflate
connection=keep-alive

Request Header Information forgery XSS

I understand the forgery problem as follows: sending an Http request is an active behavior of the client. The server listens through ServerSocket and parses the request behavior of the client according to the Http protocol.

Therefore, the information in the Request Header may not necessarily follow the standard Http protocol.

You can use the Tamper Data and Moify Headers (search Headers and Tamper Data in the FireFox extension center) Plug-in to modify the plug-in. Please install FireFox and Tamper Data: too many other plug-ins first.
Click Start Tamper and then request the Web page. You will find that the request has been intercepted by Tamper Data. Select Tamper:

Click Start Tamper and then request the Web page. You will find that the request has been intercepted by Tamper Data. Select Tamper:

Modify request header information: commandid

Requests received by the pipeline Servlet Request:

Enumeration e = request. getHeaderNames (); while (e. hasMoreElements () {String name = (String) e. nextElement (); // obtain key String value = request. getHeader (name); // get the corresponding value out. println (name + "=" + value + "<br>"); // outputs such as cookie = 123} response}

Source code download: http://pan.baidu.com/share/link? Consumer id = 166499 & uk = 2332775740

Use Moify Headers to customize Headers:

In some business logic, programmers need to record the user's request header information to the database, and once the forged Request Header arrives at the database, it may cause xss, or SQL injection is caused when the database is not available, because for programmers, most people think that the data obtained from Headers is safe and reliable, you can spell SQL with confidence (remember that Discuz has such a vulnerability ). In May January this year, I found that xss.tw also had such a classic case. The Wdot buddy did not translate special scripts when recording the user's request header information, as a result, we store the data directly to the database through forged request headers.

Because the XSS.tw platform does not process the request header, you can use the XSS silk to attack the High-rich black. When I first came back, I was blown up with the wind. By modifying the request header information to an XSS script, the xss platform directly receives and trusts the parameters. Because few people may suspect the information of the request header, the stored XSS is caused. Once others log on to xss, their XSS code will be automatically executed.

Xss.tw because the ID is easy to predict, it is easy to affect all users:

Bytes

So one day, all the xss.tw users were played by www.gov.cn with the two products:
Bytes

Forge Http request headers in Java

The code will not be pasted. Set setRequestProperty when sending the request, for example:

URL realUrl = new URL (url); URLConnection connection = realUrl. openConnection (); connection. setConnectTimeout (5000); // connection timeout. setReadTimeout (5000); // read timeout connection. setRequestProperty ("accept", "*/*"); connection. setRequestProperty ("connection", "Keep-Alive ");(.............................)

Test Servlet:

Bytes

0x01 Session

Session is a Session stored in the server memory. We know that Http is a stateless protocol. to support interaction between the client and the server, we need to use different technologies to store the interaction status, these different technologies are Cookie and Session.

Set a session:

Session. setAttribute ("name", name); // obtain the user's name from the request and put it into the session to resume the session. setAttribute ("ip", request. getRemoteAddr (); // get the IP address of the user request out. println ("Session set successfully. ");

Directly obtain the session. If we can see that the SessionId obtained from the same URL in FireFox and Chrome is not the same, it indicates that SessionId is unique. Once the Session is successfully set on the server side, we can always share the session information corresponding to this SessionId in this session, and the Session has a validity period, which is generally 20-30 minutes by default, you will see that the xss platform usually has a feature called keepSession, which is requested every time with the sessionId. In fact, it is in the process of keeping the session valid and does not expire.

Session lifecycle (from creation to destruction)

Reset timeout 1. The default expiration time of the session is 30 minutes, and the maximum modification time is 1440 minutes (1440 divided by 60 = 24 hours = 1 day ).

Restart 2. The server restarts or the Session is disabled.

Closed Note: closing the browser does not actually invalidate the session! Because sessions are stored in the server memory. How can I know if the client closes the browser on the server? The correct explanation may be that the session information between the client and the server will not be remembered after the browser is closed, and the server does not write the sessionId to the Client Cache as a Cookie, after the browser is re-opened, it does not take the previous sessionId to access the server URL. If the server does not get the sessionId from the request, it naturally feels that the session does not exist (as you understand ).

When we disable the server, Tomcat will create the SESSIONS. ser file under the \ work \ Catalina \ localhost \ project directory. This file is the file persistent to the hard disk when the Session stops Tomcat. all currently accessed user sessions are stored in this file. after Tomcat is started successfully. SESSIONS. the file will be deserialized to the memory, so the file disappears after the startup is successful. under normal circumstances, you do not need to log on from the start of Tomcat. note that the user class corresponding to the User object stored in the Session must be serialized. (From: http://alone-knight.iteye.com/blog/1611112)

What is SessionId? What is the purpose?

For example, to steal the sessionId, visit: http: // localhost/Test/SessionTest first? Action = setSession & name = selina to create a session. Bytes

Enable Both FireFox and Chrome to set two sessions: too many sessions

Let's take a look at what the current user's request headers are like: too many requests

Zookeeper we still use TamperData to modify the jsessionId in the requested Cookie. The following is a time to witness the miracle:

What I want to say is already included in the text comment in the image. Do the great Xss Hackers understand it? You may steal jsessionId (jsessionId in Java), not just cookies. If our Session is set to be very long, the SessionId will be retained for a long time, providing a unique condition for Xss attacks. This Session will waste the server's memory for a long time and cause the SessionFixation attack! Zookeeper

How to deal with SessionFixation attacks

Authentication token 1. The user enters the correct creden。, the system authenticates the user, completes logon, and creates a new session ID. Bytes

2. Session and Ip address control

3. Strengthen the programmer's awareness of Defense: the programmer who writes an explicit xss record once, And the programmer who writes an obscure xss warning once, three or more xss programmers are found to understand the termination of the labor contract (haha, joke ).

0x02 Cookie

A Cookie is a credential [cached on the client] in the form of a file (simplified to easy-to-understand). the life cycle of a cookie mainly lies in the effective time set by the server. If no expiration time is set, it indicates that the life cycle of the cookie is the browser session period, and the cookie disappears as long as the browser window is closed. This time we use IE as an example:

When we create a Cookie: when creating a Cookie:

If (! "". Equals (name) {Cookie cookies = new Cookie ("name", name); // put the user name in cookie cookies. setMaxAge (60*60*60*12*30); // set the cookie validity period. // c1.setDomain (".ahack.net"); // set the valid domain response. addCookie; // Save the Cookie to the client sending out. println ("Current Logon:" + name);} else {timed out. println ("the user name cannot be blank! "); Token ");}

Some cool programmers directly store the account and password in plain text in the cookie of the client, so they have to admire their profound skills. Open the client in notepad to view the password of your account.

Continue to read the Cookie:

I think I don't need to explain how to store cookies in plain text on the client? File and Data! The most direct way for the hacker to steal cookies is xss, which uses the IE browser to output the cookies of the current site:

javascript：document.write(document.cookie)
    
    

Zookeeper first we use FireFox to create a cookie: zookeeper

Then TamperData modifies the Cookie:

In general, the cookie is directly sent to the server. Programmers over-Trust the client cookie value so that we can log on to the backend without knowing the user name and password, or even cookie injection. Jsessionid is also placed in the cookie, so the jsessionid is obtained for the cookie, and all the information in the corresponding session is obtained for the jsessionid, what if the jsessionid exactly belongs to the administrator?

0x03 HttpOnly

We use

javascript：document.write(document.cookie)

The cookie information stored on the client can be obtained through the document object.

After HttpOnly is set, you cannot use document. cookie to retrieve the cookie value.

After HttpOnly is added, an HttpOnly will be added after the original cookie;

Common cookie settings:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;

Cookie after HttpOnly is added:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly;

(Refer to YearOfSecurityforJava)

You have set HttpOnly directly in the Java EE 6 API:
Bytes

API description:

Generally, if isHttpOnly is set to true, the cookie will be identified as HttpOnly, which can solve cross-site scripting attacks to a certain extent.
Bytes

Starting from servlet3.0, you can set HttpOnly directly through setHttpOnly. In fact, even if it is not JavaEE6, you can add HttpOnly to the set Cookie so that the browser knows that your cookie needs to be managed in HttpOnly mode. While ng a in the new Servlet not only can manually go to setHttpOnly can also by adding cookie-config in web. xml (HttpOnly is enabled by default, note that the configuration is web-app_3_0.xsd ):

<?xml version="1.0" encoding="UTF-8"?><web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee     http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">    <session-config>        <cookie-config>            

You can also set the session validity period (30 points ):

<session-timeout>30</session-timeout>

0x04 CSRF (Cross-Site Request Forgery)

CSRF (Cross Site Request Forgery, Cross-Site domain Request Forgery) user requests are forged to construct malicious requests as victims. (Classic parsing reference: http://www.ibm.com/developerworks/cn/web/1102_niugang_csrf)

CSRF attack object

Before discussing how to defend against CSRF attacks, we must first clarify the objects of CSRF attacks, that is, the objects to be protected. From the above example, we can see that CSRF attacks are used by hackers to obtain the trust of the server by using the cookie of the victim. However, hackers cannot obtain the cookie or see the content of the cookie. In addition, hackers cannot parse the results returned by the server due to browser same-origin policy restrictions. Therefore, a hacker cannot get anything from the returned results. All he can do is send a request to the server to execute the command described in the request and directly change the data value on the server side, instead of stealing data from the server. Therefore, we need to protect services that can directly generate data changes. for services that read data, CSRF protection is not required. For example, the transfer request in the banking system will directly change the account amount and be attacked by CSRF, which requires protection. While querying the balance is a read operation on the amount and does not change the data, the CSRF attack cannot parse the results returned by the server and does not require protection.

Csrf attack methods

Object: A: common user, B: Attacker

1. Assume that A has logged on to xxx.com and obtained A valid session. Assume that the user center address is. 3. B by building a transfer link URL such as: http://xxx.com/ucenter/index.do? Action = transfer & money = 100000 & toUser = (B's account), because A has logged on, the backend can certainly obtain A's information when verifying the identity information. B can create such A URL through xss or other sites to seduce A to click or trigger Xss. Once A sends a get request with its own legal identity, the RMB 100000 of a will be transferred to B's account. Of course, this low-level security problem rarely occurs during transfers and payments.

Defense CSRF:

Verify that the HTTP Referer field adds a token to the request address, verifies custom attributes in the HTTP header, and verifies the added Verification Code (copy defense CSRF is meaningless, refer to the URL of the IBM topic above)

The most common practice is to add token, Java inside the typical practice is to use filter: https://code.google.com/p/csrf-filter/ (link provided by plt, source code above in: http://ahack.iteye.com/blog/1900708)

CSRF introduction drops existing articles, can refer to: http://www.bkjia.com/Article/201307/226880.html