Username:
Password:
Figure 1: Simple login site
The HTML form in the above example at first glance is very simple but has many potential risks. Assume that the user accesses the address http://www.sampleweb.com/login.html and enters the username 'admin', the password is 'testpassword', then press login. The task of the form is to get the username and password and then use the POST method to send the request to a web application that checks the login on the server named 'login.asp'. However, if you analyze it more carefully, you can see that this login page reveals many loopholes that hackers can take advantage of. The most obvious thing is that when the user accesses the http:/// address, the data is transmitted on the network from the user's browser to the server in the form of plaintext, ie unencrypted. So just having a network sniffer program like Ethereal and a bit of luck and patience, an average hacker sitting on another client can catch get the HTML messages transmitted from the user machine above. Below is the content of such a message:
[POST /admin/login.asp HTTP / 1.1Accept: image / gif, image / x-xbitmap, image / jpeg, image / pjpeg, application / vnd.ms-excel, application / vnd.ms-powerpoint, application / msword , application / x-shockwave-flash, * / * Accept-Language: en-usContent-Type: application / x-www-form-urlencodedAccept-Encoding: gzip, deflateUser-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: www.sampleweb.comContent-Length: 68Connection: Keep-AliveCache-Control: no-cache
username = admin & password = testpassword &% 3Fuser_role% 3F = 1 &% 3Ftries% 3F = 3
Date: Mon, 30 May 2005 09:00:34 GMTServer: ApacheExpires: Mon, 30 May 2005 10:00:34 GMTConnection: closeTransfer-Encoding: chunkedContent-Type: text / html
]
The contents of the packet captured in the bold color section clearly indicate that the request (POST request) is sent including username (username), password (password), authority (user_role), number of attempts to login (tries). and other important information. It would be more dangerous if somehow the hacker captured the control of a gateway server (Internet gateway) and ran a sniffer on this machine, then all the information from the workstations in the local network would caught by this sniffer before they are sent to the Internet. For a hacker with a rank, captured packets can be changed some important information and then continue to be sent to the server and the server's response information may not be as expected by the user but satisfying the hacker requirements.
Prevention experience:
Before discussing prevention, we need to understand that no system is perfect security, nor any absolute precautions. Efforts are only valid to a certain extent and exist for a certain period of time until people find a new way to overcome it.
To ensure high security for data exchange between users and servers, administrators often choose to use SSL (Secure Socket Layer) for the site (within this article I do not describe details about SSL and how to install servers supporting SSL, readers can refer to documents on the Internet). Then the user will access the website at https: // instead of http:/// and the exchange information will be encrypted on the transmission line with a very high level of security.
Returning to the current topic, on the user's browser, the information transmitted from the HTML form needs to be encrypted before being sent (the Yahoo mail login page also applies this method). So the site needs to install additional code to encrypt user data entered at the client level before sending a request to the server. For default values set as in the above example:
If your site really needs such default parameters, encrypt them when designing and when the server receives the request, the server will decode the parameters before processing and returning the results to the user. . For example:
On the server side, when designing the application you always remember the following principle:
Data received from the client can always be changed unintentionally, never rely completely on this data. Your application needs to filter and closely check these data as soon as it is received before proceeding with further processing.
The action attribute used to specify a web application on the server for the form object is responsible for receiving, processing information and returning the results to the user. For example: . When you know the program name, you can learn more valuable information about the web server, about the current directory of the program.
Try analyzing the action attribute in the above example, we can first see the login site located in the / admin directory on the website root directory (web root) - many web designers have the habit of placing files Important data such as database files, customer lists . into / admin or / database directory and naming is easy to guess, this will create opportunities for hackers to try. Next, we know the language of server side is ASP, which can infer the server used is IIS and Windows Server operating system. With Internet experience, hackers can easily find many security holes related to Windows IIS servers and ASP languages.
Prevention experience:
Combined with the above mentioned HTML form methods, it is necessary to minimize the explicit assignment of the directory name on the server as / admin . instead, create virtual directories (virtual directory) on the web server and web server configuration settings to redirect requests to a specific URL to the real directory on the server. Also, install and use the https protocol when calling a web application on the server, for example. This ensures the information transmitted in the request is encrypted and minimizes the possibility of being exploited.
The form's method defines how to send user input to the web server for the processing program. When understanding how to send information (POST, GET, PUT .), hackers can monitor and 'capture' the information sent on the network, can even change them and send them with other values. to create results that the administrator does not want, especially information related to the process of logging into the site. In fact online there are many tools created for this purpose, typically Brutus-AET or WebCracker capable of automatically generating GET requests or PUTs containing usernames and passwords to log in to the site from A list of usernames and passwords is available in the dictionary format.
In the method of sending requests to the application on the server, POST and GET are used mostly in HTML forms. In terms of security, the difference between these two methods in their way of operation, the POST request is placed in the header of the HTML message sent to the server (reviewing the packet capture section in the HTML form above). so this request will not be logged on the server and client, while GET request will be recorded because the sent information is placed directly on the URL, for example here:
Requests to the web application on the server via GET method will be recorded in the following places:
Prevention experience:
Saving the information and accessing requests facilitate the hacker to detect sensitive information, so to limit the possibility of being sneaked in information on logs we should note as follows:
Avoid using the GET method in the HTML form, use POST.
The server-side web application written to receive data in a specific manner (POST, GET, PUT .) needs to check that the received request is correctly sent by the supported method, if not needed. error message to users. This helps to prevent hackers from taking advantage of web-based 'detection' tools by repeatedly trying user name and password values through GET or PUT requests.
Thus, just create a copy of the login site using the View Source function of the browser and save it on the disk, then edit the contents of the test section and the address of the HTML form executable then the hacker has You can send the name and password with the desired content to the web server without being subjected to client level checking.
Prevention experience:
In this case, in addition to checking on the client side, the executable also needs additional testing on the server side when receiving the request. In the above example, in case the hacker intentionally modifies the login page to send a request for a password containing special characters such as 'testor 1 = 1--' then the login.asp page on the server You can also filter these invalid values and error messages to users.
Textbox component for users to enter information into the HTML form. If the web application does not handle the input information well, hackers can take advantage of entering special values to fool the system and create unwanted results. Here are some types of exploits commonly used by hackers for the object:
Transmission of special values requires the database system to execute data mining commands. For example, username and password values of 'testor 1 = 1--' are used in SQL Injection techniques (refer to the article on SQL Injection, December 2003 Archives - page 96) to help hackers easily log in under the authority High, thereby, can continue to take advantage of executing system commands and server controls.
Insert Cross-site-scripting script (CSS / XSS)
For example:
http://www.tipsmake.com/input.asp?data=
or
http://www.tipsmake.com/input.asp?data=
Hackers can take advantage of this kind of vulnerability to steal cookies (user information and web page access information) of the user accessing it.
Exploiting buffer overflow. In case the web application does not check the input data length, the hacker can pass a very large value (for example, a string containing one million characters A) causing server-side buffer overflow. The consequences can cause the server to stop working, even run dangerous codes attached by hackers.
Input object type is not displayed on the browser. Some websites use input objects with hidden properties to contain default values such as purchase prices on shopping sites or assign rights to data objects. Although it is hidden, it does not appear when users visit the site, but this object is not really safe and can be easily viewed by viewing the source code (View> Source) . Taking advantage of this feature, hackers can change this value to the desired value and repeat the sending operation to the web server. In merchant sites, without server-side value processing, hackers can buy items at significantly reduced prices or at no cost.
In fact, some websites have taken advantage of this situation, if assuming role = 1 is a normal user, role = 0 is an administrator and if upon receiving the web application request The server simply carries these values compared to the list of privileges in the database and extracting data corresponding to that right, an input object has a predefined value:
It is possible to change it to:
And when logging in, the user automatically carries administrator privileges. The maxlength and size values determine the length of the value entered into the input object. Hackers can change the maxlength value to allow for very long values or strings to be passed over the server side of the application. If not handled properly, they can cause errors such as buffer overflows to execute control commands or even shut down the web server.
Prevention experience:
Same as in the section.
If you use Internet Explorer 6.x, go to Tools / Internet Options menu, on the Security tab, select the Internet zone, the safe level is 'Medium' - Figure 3, then select the 'Custome level' section, In the 'Security Settings' dialog box, move the slider to the Java VM / Permissions section and select the 'High safety' level (Figure 4), continue down under the Scripting / Scripting Java applets section, select Disable (Figure 5). This method will limit the browser from allowing Java scripts and Java applets to run on websites. However, the downside is to re-enable the function if you want to allow Java code to run on trusted sites.