Methods for Passive Analysis and Circumvention

Methods for Passive Analysis and Circumvention

This section describes methods that can be used by an attacker regardless of which protection tools are used.

Examining HTML Code

The attacker always can examine the HTML code generated as a respond to particular HTTP requests . If you don't stick to the safety principles during programming, the attacker can find many interesting things on your HTML pages.

Comments in HTML code can disclose information about the system's internals to the attacker. For example, consider the following fragment of HTML code.


 <a href  =/>  Main </a> <a href  =/  news.html> News </a> <a href  =/  users/> Users </a>  <!-  <a href=/adminzone/admin.php> Administrator </a> --> 

Looking at this code, the attacker can infer that the administrator panel is at the http://site//adminzone/admin.php address. You shouldn't expose the path to the administrator panel even when it is protected with a password or other methods.

Although this address cannot be seen on the HTML page, it was there at one time and then was commented out. Therefore, it is available to anyone who examines the HTML page.

By examining the HTML view of a page, the attacker sometimes can find the folder structure on the server.


 <html  >  <head> <link rel=stylesheet href  =/  share/main.css> <link rel=stylesheet href  =/  share/menu.css> <script src='/main/cookie.js'></script> </head> <body>     <img src=/images/1.jpg> <img src=/images/2.jpg>     <img src=/test/test.jpg>     </body> </html> 

This HTML code discloses a few folders located on the server: /IMAGES/, /SHARE/, /MAIN/, and /TEST/. The attacker is likely to check whether files are available in the following folders:

  • http://site/images/

  • http://site/main/

  • http://site/share/

  • http://site/test/

In addition, the attacker can examine the names of forms, form parameters, GET requests, and so on, and he or she can make assumptions about the server structure. For example, the names of GET and POST parameters in HTTP requests are often the same as the names of variables in scripts or the names of columns in database tables.

Consider another example.

Fragment of code

 <html> <body> <form action=/main/search.php method=GET> search: <input type=text name=searchtext> <input type=submit> </form> <hr> <form action=/forum/guestbook.php method=POST> name: <input type=text name=user><br> e-mail: <input type=text name=usermail> message: <textarea name=message></textarea> <input type=hidden name=sessionid value=g84hfsn7894nap6> <input type=hidden name=userid value=32> </form> </body> </html> 

By examining this example, the attacker can guess the names of variables used in scripts and the names of columns and, possibly, tables in the database.

In Chapter 3 devoted to SQL injection, I demonstrated that in some cases it is necessary to find the names of the columns and tables in the database to exploit this vulnerability successfully. Examination of the HTML code can give the attacker information sufficient to exploit the vulnerability.

Reading Hidden Fields and JavaScript Code

HTML forms can contain hidden fields that store certain values. As the name implies, hidden fields don't show when the browser displays an HTML page. However, when you use them, you should remember the following note.


The values in hidden fields are available to an attacker.

When viewing the HTML code of a page, the attacker can easily read the values of hidden fields.

In the previous example, two hidden fields are available to the attacker: sessionid and userid . Both their names and values can be read. Therefore, you can think of hidden fields as hidden from a common user but not from a professional attacker. Don't hope their values cannot be disclosed. When planning system protection, remember that hidden values will be available to the attacker.

Suppose that the values of hidden fields are computed with JavaScript tools rather than specified explicitly. In such a situation, examination of the HTML code won't disclose the values.

Consider an example.


 <html> <body> <script Language=JavaScript> function sign1(str) {   // ... Here, a signature algorithm should be used   1=str.length;   e=1+'';   fcr(i=0; i<1; i++) e=e+''+str.charCodeAt(1);   document.f1.sign.value=e;   return e; } </script> <form name=f1> value: <input type=text name=val onChange=sign1(this.value)> <input type=hidden name=sign> <input type=submit> </form> </body> </html> 

This is the HTML code that the attacker will see when examining the HTML view of the page. The f1 form contains a hidden value, the sign1() function in the JavaScript script.

The JavaScript code is available to the attacker in any case.

The purpose of this page could be preventing the val value from sending from a source other than the form. Every time the user changes the val value in the form, the signature for this value changes. The signature algorithm can be any appropriate algorithm.

Theoretically, if the user doesn't know, which signature algorithm is used, he or she won't be able to find the sign value from a particular val value. However, if the algorithm is implemented in JavaScript, the attacker can disclose it.


The attacker always can analyze the JavaScript code loaded in the browser.

If the JavaScript code is included directly in an HTML page, it can be analyzed by the attacker. If you separate the JavaScript code into a file, the file will be available using HTTP.

A programmer can intentionally change JavaScript code with special tools without changing its functionality to make it difficult to analyze the code. However, this would merely be confusing. If the attacker is persistent, he or she will be able to analyze the code, possibly by spending much time on the analysis.

As always, you shouldn't base protection on creating confusion. What's more, such a "solution" has the reverse side. A complicated program is a problem for its creator, not only for an attacker.

In this example, the attacker can analyze the JavaScript code and find how the signature is computed from a value.

However, in this case (and in many similar cases), the attacker doesn't need to analyze the code. He or she can cut the sign1() function and paste it, for example, into his or her HTML page to investigate, which values it returns for particular input values.

The attacker can find the new sign value immediately after it changes. To do this, he or she would call the JavaScript code in the navigation bar of the browser.

In this example, after the http://localhost/6/3.html page is loaded and the val value is computed, the attacker can enter the following code instead of the URL of the page and hit the <Enter> key:


As a result, the browser will display an alert message with the current value of the field.

This method can be used to find the current values of hidden fields without additional analysis of an HTML page. It also can be used to find the value returned by any JavaScript function on the page, such as in the following example:


In this example, you can see the signature just by clicking the submit button and looking at the URL because the val and sign values are sent with the HTTP GET method. Even if they were sent with the HTTP POST method, it would be possible to analyze traffic and find the signature after it is sent.

However, the attacker sometimes needs to know the signature before it is sent or he or she needs the value of a hidden parameter or the value returned by a particular function.


Embedding JavaScript into the browser's address line can be different in different browsers.

Now, imagine a situation, in which the attacker needs to change the value of a hidden parameter in a form. Consider the following script.


 <? echo"; <form name=f1 method=POST> <input type=text name=v1> <input type=hidden name=user value='guest'> <input type=submit> </form> "; if(!empty($_POST['user'])) {  echo "  user $_POST[user]:<br> $_POST[v] "; } ?> 

Suppose the attacker wants to send a message on behalf of the administrator, that is, he or she needs to change the value of the hidden field from guest to administrator .

The most common solution would involve saving the page on the disk and changing it appropriately. However, because the action attribute of the form isn't specified, the attacker would need to add it to the saved page. (Similarly, if it was specified with a relative path, the attacker would need to change it)

In this example, the form should be sent to the current page, http://localhost/6/4.php . Therefore, the action attribute should have the same value.

In another situation, the attacker would need to add the server name, the protocol name, and possibly a path. For example, in the http://site/forum/main.php script, the attacker would need to change

  • action=post.php to action=http://site/forum/post.php,

  • action=/index.php to action=http://site/index.php,

  • and /news/list.php to action=http://site/news/list.php.

Values such as action=http://site2/main/index.php that already contain the full address with the protocol shouldn't be changed.

In addition to editing hidden parameters of the form, the attacker might want to specify another type for them to make editing easier. In this example, the attacker could save http://localhost/6/4.php on the hard disk and edit it as shown in the next example.


 <? echo " <form name=f1 method=POST action=http://localhost/6/4.php > <input type=text name=v1> <input type=TEXT name=user value='administrator'> <input type=submit> </form> "; if(!empty($_POST['user'])) {  echo "  User $_POST [user]:<br> $_POST[v1] "; } ?> 

The script that receives HTTP GET or POST parameters from a form cannot know the types of fields, from which the parameters were sent.

However, this method won't work if the receiving script checks the Referer header of an HTTP request. In such a case, the attacker can create an HTTP request using a direct connection to the HTTP port of the server, using specialized utilities or scripts, or using specialized software that changes headers of an HTTP request in real time.

In some cases, the attacker can execute JavaScript in the address line of the browser to change the values of hidden and other parameters of a form and submit the form. For example, to change user to administrator and submit the form, the attacker would load the http://localhost/6/4.php page, enter the following code into the address line, and press the <Enter> key:


If the form has no name, the attacker can change its attributes by accessing the forms property:

 javascript:document.forms[0].user.value=    'administrator';document.forms[0].submit(); 

Note that the JavaScript code is executed on the client's browser; therefore, no filtration on the server can prevent the JavaScript from being executed.


The protection should be based on an assumption that a malicious person can use JavaScript at any moment to view, delete, or edit any hidden parameters whose values are set during the generation of an HTML page or after the page is loaded. In addition, the malicious person can close JavaScript code and forge values returned by any functions.

Hacker Web Exploition Uncovered
Hacker Web Exploition Uncovered
ISBN: 1931769494
Year: 2005
Pages: 77 © 2008-2017.
If you may any questions please contact us: