Tải bản đầy đủ - 0 (trang)
11  Reading Private Data via JSON Hijacking

11  Reading Private Data via JSON Hijacking

Tải bản đầy đủ - 0trang

If it does return data, check the JSON response data to see if your server includes any

specific protection against JSON hijacking. If your application returns confidential, but

unprotected JSON data upon request, you should flag it as vulnerable to JSON hijacking.

For example, an AJAX application may send a request to http://www.example.com/

json/clientInfo.jsp?clientId=3157304449. If this page immediately responds with

JSON, such as {"user": { "fname": "Paula", "lname":"Brilliant", "SSN":

"078-05-1120" }, "accountNumber": "3157304449" }, then it’s likely this application is

vulnerable to JSON hijacking. An attacker could inject JavaScript to submit requests

for many identifiers, gathering information on each account.


Note that this recipe applies in two situations. First and foremost, if your application

displays this data without any authentication, you can be sure it can be read by a malicious attacker just by navigating to the page. The case where such protection will help

is if the data is also available to a logged-in user and an attacker executes a CSRF-like

attack against that user. For example, gMail was susceptible to a JSON hijacking attack

where a victim would visit the attacker’s website. The attacker’s website would issue

a request to gMail for their contact list, and if the victim was already logged in, the

attacker’s page would receive and parse the JSON, and finally submit the data back to

the attacker’s server.

After authentication is in place, JSON hijacking protection can take a variety of forms.

Google appends while(1) into their JSON data, so that if any malicious script evaluates

it, the malicious script enters an infinite loop. Comment characters such as /* and */

should be sufficient to escape the entire string, rendering it unable to be evaluated.

Using our example above, if the string read while(1); {"user": { "fname": "Paula",

"lname":"Brilliant", "SSN": "078-05-1120" }, "accountNumber": "3157304449" },

then it would be protected—a script evaluating it would be stuck in an infinite loop.

JSON serialization is a way to transmit data in an easily parsed format. Javascript can

parse JSON using the built-in eval() function, although this is discouraged. Using the

eval() function without any other validation is a weakness that may be exploited by

code injection. It’s not worth the risk, so people have now written full-fledged JSON

parsers that include validation. You can find references to them at http://www.json.org.

Some websites are now purposefully offering public (non-confidential) data via JSON.

They hope that other websites will read this data, in order to create mashups or other

services. This recipe only really applies when the data being published is confidential

or otherwise private. For example, Google’s gMail would reveal one’s address book

contacts via JSON hijacking, which was an obvious vulnerability. Meanwhile, Reddit

(a social news site) offers JSON feeds for nearly all of its public news feeds, which is

just an additional feature. You can find Reddit’s JSON feed at http://json.reddit.com.

214 | Chapter 10: Attacking AJAX


Manipulating Sessions

It is one thing to show a man that he is in error, and

another to put him in possession of truth.

—John Locke

A session, at the most basic level, refers to all the connections a web browser makes to

the web server during a single normal use. You can think of a session as a single sitting;

the time and activities from when a user first browses to the application until the user

logs out is one session. There are two aspects to establishing and maintaining a session.

The first piece is a unique “session ID,” which is some kind of identifier that the server

allocates and sends to your browser (or other client, like Flash Player). The second piece

is some data that the server associates with your session ID. If you are familiar with

databases, you can think of the session ID conceptually as a row in a database that

corresponds with all the things you’re doing (the contents of your shopping cart, the

expiration of your session, your role in the system, etc.). The session ID, then, is the

unique key that the server uses to look up your row in the database. In some systems,

that’s literally how it is. In other systems, the actual storage of sessions is completely

different, but conceptually they work this way.

Maintaining data during a session makes life easier for users. The shopping cart metaphor is a prime example—online shopping carts retain the items you place in them

until you log out or abandon the site. Without maintaining session data, the application

would treat you as a new person every time you went to a different page. Sessions do

more than just remember bits and pieces of convenient data—they are also used to

store authentication information. They remind the application of who you are, every

time you request a new page. Because sessions contain the keys to your identity, data,

and activities within a web application, they are a prime target by malicious attackers.

Despite how common the use of sessions is, they can be implemented in a variety of

complex ways. Identifying and manipulating sessions will require the use of many

techniques described in earlier chapters.


Session mechanisms vary on a couple of different axes. There are two places where

session information is stored—in the client and in the server—and there are two places

where the session information is typically transmitted—in cookies or in requests. The

storage and transmission methods are independent of each other, so that gives us four

possible session mechanisms. Table 11-1 shows all four variations and contemplates a

fictitious shopping cart application. The shopping cart application needs to track both

the shopper’s current session ID (assuming the shopper has already logged in) and the

current contents of the shopper’s cart. Each of the four variations in Table 11-1 tells

you where those things are stored and where they are transmitted.

Table 11-1. Session mechanism variations

Storage location

Transmission method



In cookie

Session identifier and contents of the

shopping cart are both in the cookie.

A session identifier is sent in the cookie, but

the contents of the shopping cart are stored in

some server-side data storage, like a database.

In request

The session identifier is probably a

hidden form field or a URL parameter,

and the contents of the shopping cart

are also passed in form fields or URL


A session identifier is passed either in the URL

or in a hidden form field, but the contents of

the shopping cart are stored in some serverside data storage, like a database.

This chapter is all about testing the limits and the behavior of your application with

respect to how it handles sessions. If your application uses weak session identifiers (e.g.,

predictable ones), then an attacker can guess the session IDs of victim users and then

impersonate those users. If your application exposes the session information (e.g., the

user’s role, the prices of things in their shopping cart, their permissions) in a place where

the user can actually manipulate them (e.g., in the web request itself), then an attacker

can send unexpected inputs and hope to make your application misbehave. Throughout this chapter you will see how to find session IDs and session data, and then you

will see how to analyze and manipulate both.

11.1 Finding Session Identifiers in Cookies


You need to find the session identifier that your application uses, and you’re going to

start by looking in the cookie. Remember, however, that just because you find session

information in the cookie, it doesn’t mean that’s the only session information used in

the application.

216 | Chapter 11: Manipulating Sessions

Figure 11-1. Viewing a request with TamperData

Figure 11-2. Viewing cookie details with TamperData


Use either TamperData (Recipe 3.6) or WebScarab (Recipe 3.4) to view the request. In

this recipe, we are focusing on session data in cookies, so just look at the Cookie: header

in the request. Figure 11-1 shows the normal TamperData window with ongoing

requests displayed. This was a visit to the main united.com web page, which obviously

sets a cookie. After double-clicking on the Cookie line in the request, a window like

Figure 11-2 opens up and displays the various components of the cookie.

The simplest thing to do is to search for the string “session” in one form or another.

Most of the time, you’ll come across a parameter that is a variation on that theme.

Some popular ones are: JSESSIONID (JSP), ASPSESSIONID (ASP.NET), or plain sessio

nid (Django). Sometimes you may have to search for PHPSESSID (PHP) or _session_id

(Ruby on Rails). In some more rare cases you’ll see a RANDOM_ID (ASP.NET). If you see

any of these in the cookie values, then you’ve probably found your session identifier.

11.1 Finding Session Identifiers in Cookies | 217

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

11  Reading Private Data via JSON Hijacking

Tải bản đầy đủ ngay(0 tr)