IBM Rational AppScan: Attacks Web applications with cookie tampering

Features of cookie tampering riskCookie tampering is a technology known for its ability to obtain simulated and privacy leaks. It is achieved by maintaining session information manipulation for the customer's (or end user) identity. By creating these cookies, a hacker can simulate a valid customer, so that he can obtain detailed information and execute actions that represent viruses. This capability is derived from the fact that session cookies (or, more broadly, session identifiers) are not secure. The endless work of internal session maintenance in Web Application Programming, session management is complex and clumsy. Programmers will worry about many aspects of session management, which can divert their/her attention from the main goal: to execute this business logic that makes the website unique and useful. Question: • Session creation and recognition: How can you determine when a new session is required and it has already been created? The programmer must identify that a customer actually needs a session, create the session, and assign the customer a session. • Concurrency problem: when two customers access the website at the same time, each requires a new session, so it is necessary to ensure that the session creation process is still running correctly. • Session termination and suspension: What causes a session to terminate? How are these terminated session resources recycled again? What happens when a customer accesses this website during the termination process? What happens when a customer accesses a website with a session? • Session data storage, multiple servers, failed. Where is the session data stored? On disk? On random memory? What kind of high-performance penalty will there be? If a customer accesses the first server (and establishes a session with it) and is directed to the second server by the Server Load balancer, so what will happen on a multi-server site? If the original server breaks down, what will happen to the customer's session data? Anmingzhi, the following points are very important and worth thinking: • it is almost impossible for a customer to predict what another customer accepts, what is being accepted, or what is to be accepted. This is obviously a simulated attack that must be prevented, and thus violates the right to privacy. • Ideally, when visiting a site, the customer cannot predict the next identifier they will obtain. This is useful for minimizing damage to identity theft when it is roaming back and forth (unblocked), and it is also useful on customers' computers. • Any identifier should have a reasonable period of time-it can be stolen again to minimize damage. As you said, it is not very easy to implement all requests, especially when the session mechanism develops into a wireless self-organizing network. Developers, especially those who are not very familiar with security, will have more complex security requirements to clarify that they are more easily forgotten. There are many examples of security issues in the logo. These are well proven in MIT Laboratory for Computer Science (see Dos and Don't 'ts of Client Authentication on the Web by Kevin Fu, Emil Sit, Kendra Smith, nick Feamster ). In this way, it is quite difficult to produce a good session management solution, let alone a secure session management solution. This is one of the reasons why application servers are so popular. Application Server and Engine: an Application Server (or Application Engine) is a software program used to make the work of this Application developer easier. It is usually convenient for developers to compile HTML pages, and these pages contain server embedded instructions to instruct the server to execute various tasks. Most application servers provide application developers with an environment for automatic session management, saving them from all the concerns mentioned in the previous sections. Application Server case: • Microsoft®ASP. NET is run at the top of IIS • Macromedia • ColdFusion • Apache Tomcat • Apache JServ • PHP • BEA WebLogic • IBM®WebSphere®Application Server. The Internet Cookie Report page of the Security Space Web site combines the names of these cookies with the servers that issue them to provide frequency analysis. Of course, this is not comprehensive, because some servers and sites use tags in the form of parameters rather than cookies. The application engine reflects the fact that they completely release program developers from worries about session management. The session management function is usually managed in a better way, rather than what internal programmers can achieve. The application engine reflects the fact that they seem to release programmers from concerns about identity security. However, we can see from the fact that the damage is far from this. In fact, some very popular applications do not provide Security Identifiers at all. Therefore, programmers are aware of security errors. My partners and I have detected that these identifiers are generated by two very popular application servers. In these two cases, we once proved that this logo is not as casual as it looks, it is only possible (in one case, it is relatively simple) the value of the next session (the session of different customers) is predicted. Case 1. Defeating a time-based identity attack is a very popular commercial application engine. This product uses two cookies to identify a session. The pair formed by two cookies identifies a session. The first cookie is just a calculator, which is added every time a new session is generated. It probably makes sure that there cannot be two identical pairs. The second cookie is to identify the cookie, which is obviously guaranteed by "unpredictable. If we can easily predict the first cookie, the first cookie we are concerned about here will be identified as a TOKEN. At first glance, the TOKEN looks like a random sequence of Octal numbers. The entropy here is 108 = 226.57. It may have been fully considered. It is feasible to try so many requests (0.1 billion times, instead of a website with no control warnings or attention. However, you will find that, in fact, TOKEN meets the following equation: We use t to represent the GMT time, calculated in seconds, because 01/01/1970, which is the same as the settings on this application server. We use m to indicate the minimum unit of MS on this application server. So: TOKEN = (31415821 * (t + m) + 1) mod 100000000 we noticed that t can be extracted from the HTTP Date header returned by the server, together with the first cookie setting. This means that the TOKEN cookie is completely predictable. In fact, if someone knows the time T </-t <T + △t (by second) during cookie generation ), it can be inferred that the TOKEN has a delta T + 1000 value, rather than a brief list of some values. It may take several minutes to test the server for more than thousands of values, during which the victim may remain active. This is the general point of an attack algorithm: obtain the first pair (id1, TOKEN1 ). Record t1-server time (starting from Date HTTP header) and wait for delta T seconds. Obtain the second pair (id22, TOKEN2 ). Record t2-server time starting from Date HTTP header ). If (id2> id1 + 1) starts, // We can insert a session of the victim here. For (x = t1; x <t2 + 1000; x ++) // It is only the start of the delta T + 1000 iteration to try this pair (id1 + 1, (31415821 * x + 1) mod 100000000) Termination in fact, it is possible to improve this algorithm in some cases by exploiting this fact. In some operating systems, the minimum unit of the counter is not accurate to the granularity of milliseconds, but a coarse granularity of 10 milliseconds. This can be used to reduce the search space. The attack described above allows an attacker to assume the role of a victim, assuming that such a victim is assigned to two sample attackers composed of site cookies. Because attackers can repeat such algorithms multiple times, attackers may obtain these cookies for customers at the cost of sampling the site (that is, one request per minute). In addition, each time a new customer is found, there are 1060 requests. As mentioned above, sampling at a closer interval (every second) and using the minimum unit granularity of the clock are possible, in this case, 100 requests may be sent to each new customer. If you download this site during network congestion and perform a customer simulation attempt, the extra hundreds or thousands of requests will not be noticed, at least not immediately. Case 2. When Random () is not Random, in this example, we handle an application engine that is still popular (but somewhat outdated. This engine generates a separate cookie (we call it ID) for each new session, including three mandatory regions (F1, F2, and F3) and a multi-Serial body that can be selected (the server configuration is subordinate) region (F4, before the end of the period. These regions are shown below: F1 = 6 string (A-Z0-9)-PRNG (Pseudo Random Number Generator) data, representing F2 = 3 string (A-Z0-9) with base 36 leading zeros) -server time (millisecond), divided by 2000, absolute value 363 (= 46656), expressed with base 36 leading zero F3 = 3 string (A-Z0-9) -The session is calculated in these two seconds. The basic 36 is used to represent the 36 F4 = unchanged string (each server). As you can see, F4 (if it exists) is a constant, so you can make trivial predictions. F2 is only the server time (in seconds) divided by 2, the modulus is 46656, it is completely predictable, and F3 is not particularly unknown-It grows continuously every two seconds over time (usually starting from 1 ). The only interesting area is F1. Obviously, it has enough entropy to ensure the security of this system, because it can assume a value of 366 (= 231.0 ). However, what seems safe at first glance is actually not that safe when performing a complete analysis. In Appendix A, I explained how and why F1 can be predicted. Because it is too long, this part is not included here. The fact that F1 solves the problem is that it uses a PRNG (Pseudo Random Number Generator), which is essentially predictable. Therefore, we need to know a few F1 values to fully predict this PRNG, that is, the future (and past) F1 value. This is the summary of an attack: preparation: it is possible to obtain three IDs at the minimum interval. Extract the PRNG internal State (as described in Appendix ). Obtain an ID for the interception period, and record the server time, t. Simply put, assume that t is an even number. Find out the status that PRNG used internally to generate this ID (as described in Appendix) and wait until the delta T Second (where the delta T is an even number) to get a new ID. Add this PRNG and record the internal status between the old ID and the generated ID (as described in Appendix ). Let the list of internal values be L/△t/2 iteration: for (T = T; t <T + △t; t + = 2) begin for each internal PRNG state L, I. begin Try an ID cookie consisting of: F1 = generate from sample of PRNG at state I and I + 1; F2 = T; F3 = 1; // first session in this 2-second time period F4 = F4 of any ID above; // constant per server end as you can see, it is feasible, although important, you can predict some ID cookies. For feasibility, it requires that the interval (△t) be very short (and relevant to the expected use of this server), in order to minimize the length of L (possible list of internal PRNG states ). If these intervals are indeed very short (no more than two seconds) and are correctly timed, it is possible to determine whether a new session is inserted within the current two seconds, it can make this attack more efficient (only when it understands that a new victim session has been created does it need to enable additional requests ). It should also be mentioned to avoid the loss of synchronization with this website (synchronization of the PRNG internal status), but also to keep the status of requests for new IDs from time to time, in this way, attackers can enhance the internal PRNG status of the new value. Remember that PRNG may be used for various purposes, which leads to a fast de-synchronization (to be calculated for it, it needs to be synchronized again in a closed interval, such as every few minutes ). On the other hand, by checking other random values of the application on this website, the internal status of PRNG may be clearer. This may provide a shortcut to save a lot of Computing Energy. It is worth noting that when this attacker synchronizes with this website, if IDs can be frequently extracted, it is possible to simulate any client in the consumption of sending some requests (it depends on the use of PRNG ).Opinions of related suppliersVendor 1 acknowledges these defects and notifies us that its consumer customers should use SSL certification for session and management. Although this may be good news for some consumers (but it is clear that not all consumers, because moving to SSL and SSL authentication is indeed important and sometimes impossible ), the documentation of this product guides readers to believe that the embedded session management is secure (in their documents to developers, they call it a "customer security identifier "). Of course, this supplier did not disclose this suggestion. Vendor 2 acknowledged these defects and wrote to us: "session cookies are not a substitute authentication identifier. A session cookie in a connection is a reasonable mechanism with a random identity or login review. This can be achieved by designing a script-based session, even if the session ID here is 'true' today '." Therefore, they put this responsibility in the hands of developers. Both vendors recognized the problem technically, but disband it into a non-security issue. That is to say, two suppliers assume that their consumer customers execute their own session security identity, rather than relying on the identity of this supplier. Therefore, they claim that their identity is only used (or should be used) it is better to distinguish different users, rather than as a security evaluation. In this document, we did not find any warning about using this identifier as a secure session identifier. Furthermore, the document of Vendor 1 uses a phrase that directs the user to believe that this identifier is safe. However, the vast majority of websites use the identifier published by the supplier as the security session identifier, ignoring the fact that it is flawed. In a sense, application developers return to this consistency problem: developers cannot trust this embedded session validation mechanism. Therefore, they stressed using their best effort to write their own mechanisms to achieve all the requirements mentioned above and avoid the subtle traps of the password system.ConclusionVirus intrusion causes high frequency of session security issues. The Vendors does not correct it or care about it, or delegate this responsibility to developers. Internal development is prone to errors and requires a deep understanding of security. This article provides real examples of insecure business application engines and their own applications. The conclusion is simple: the world of Web applications should include three parts: • Applications (which are developed internally and express business logic, and the novelty and uniqueness of the Company or website ). • Application environment (this application engine and Web server make software development easier and focus on applications rather than organizational structures ). • The Web Application Security component, which is responsible for the security of the software, will be used by developers again (to some extent, it is also the developer of this application engine !) They are relieved of their application security concerns. In the case described here, obviously, the Web application firewall should strengthen the application engine or internally developed applications to generate Identifiers (developers do not even need to be aware of this problem ). He should ensure that the identity sent to the application is true, not false, by using a strengthened password system and security testing mechanism.