One of the most attractive business frontiers is E-commerce. For the first time in history, a business can have its doors open to the entire world where users can make purchases with nothing more than their credit cards in hand. Businesses are drawn to E-commerce to disseminate company information, sell products and services, provide customer service, and gain a competitive advantage. Most organizations with a presence on the World Wide Web have installed preventive and detection controls in the form of installing DMZs, firewalls, and intrusion detection equipment, and hiring competent employees. Senior managers are surprised at what an attacker can do with a Web-browser and a little creativity.
Auditors must be aware there are logical steps in reducing risks, but the majority of vulnerabilities are found in faulty programming, misconfiguration, and absent systems monitoring.
Auditors must be aware that risks are controlled by:
-
Knowing the organization's critical assets
-
Knowing threats and vulnerabilities
-
Implementation and compliance with policies, procedures, and standards; primary concerns include but are not limited to:
-
Change control management
-
Code development and maintenance
-
Quality assurance testing
-
User acceptance testing
-
Effective and continuous audits
-
Continuing risk management
HTML Examination
As a logical first step, auditors should carefully examine the HTML, HyperText Markup Language, composition of the organization's Web site. Attackers examine the Web page coding as one of their first steps to gaining as much knowledge as possible about their targets. Basically, auditors should download all the pages comprising the organization's Web site and examine the HTML coding. Often there are valuable programmer comments, passwords, telephone numbers, names, contractor's information, and business addresses, commonly placed within the HTML. For example:
An examination of this Web page HTML reveals the XYZ Corporation is using an outsource Web design firm, and the page designer has listed her name and contact information. This information could be very useful to an attacker who was interested in doing a bit of social engineering with Alice Doe or her employer.
Testing for Indexed Directories
Auditors should obtain a list of the indexed Web page directories. The manual process is a slow one, where the browser is used to request specific directories. For this reason, it is more expeditious for the auditor to obtain a list of indexed directories from the Web page administrator. However, if a true outside view is sought, the auditor can deploy her browser in this fashion (http://www.xyzcorporation.com/images).
If the browser returns the images directory, it is important for the auditor to examine each and every file related to the Web site. More than once, auditors have discovered files that were not innocent files.
| Experience Note | While conducting an audit of a client's Web site, the auditor began to survey the files accessible from the URL address line of the browser, using the format of www.xzycorporation.com/files. After downloading the files, it was discovered that one of them contained personally identifiable employee information. |
Web Server Examination
Auditors may frequently access a company's Web site and determine the presence of specific Web servers. In UNIX and Windows environments, auditors may use the telnet client. By requesting a bogus file, the server file returns an error message and often the Web server will be correctly named. With this knowledge, an attacker merely researches the Internet for known vulnerabilities and executes them. For example:
Another useful tool for auditors is found at the Web site www.netcraft.com. This tool is useful whether Web sites are SSL, Secure Sockets Layer, enabled. By completing a few entries, the netcraft tool will display information about the particular Web site of interest including the Web server and operating system.
| Experience Note | It is possible that savvy administrators have changed the banners in their server responses, so it is beneficial to verify the information before listing it as a possible finding. |
Although this is not considered a high-risk vulnerability, but there are many advantages in concealing system information from attackers. Attackers using techniques to identify the Web server and its version will browse the Internet in an effort to obtain vulnerability information that can be used to exploit the server. So, if they do not have accurate information, they must resort to another means to identify the Web server. It is not a perfect remedy. Efforts to conceal information will often discourage the casual attacker but probably will not dissuade the more-motivated ones.
In a Window's environment, the HTTP server field may be edited via a hex editor in the W3SVC.DLL file and in a UNIX environment, the TCP/IP stack may be changed following the instructions at http://ippersonality.sourcefourge.net. It is suggested that the Web server response should be changed to reflect something nonsensical such as Vital O/S 2003.
There are many advantages in the practice of security through obscurity. Auditors have a variety of tools available when mirroring a Web site. The advantage of mirroring a Web site is that auditors can view it at their leisure and conduct an in-depth review of the HTML as well as its construction. There are Web site mirroring tools at www.webstripper.net, www.esalesbiz.com/extra, and www.softbytelabs.com.
Web site mirroring software will generally follow all links on a Web site and copy discovered files to the auditor's hard drive. In configuring them, rules can be set limiting the software to specific domains or preventing downloading certain file types.
Once a Web site has been downloaded, the auditor can open the pages in a simple text editor application, such as Notepad or Vi, and review the HTML content. Auditors should review coding for e-mail addresses, names, addresses, passwords, and other information useful to an attacker.
Accidental Error Messages
It is not unusual for Web servers to mishandle unanticipated user input. They fail to adequately address incorrect input and frequently provide verbose error messages that can provide valuable information to an attacker. For example, if a user incorrectly entered her user name information, the system might respond with an error message such as We were unable to find an account for this user name, click here to enroll. If the user inputs an incorrect password, the system might respond with an error message such as You have entered an incorrect password, you can reset it by clicking here.
Attackers can use overly informative error messages to either launch a denial-of-service attack or attempt to engage a brute-force attack against the password entry. A more appropriate error message is one similar to: There has been a user error; please provide the correct input. Auditors must be mindful that authorized user logons should never be the same as the user names used by the organization's e-mail naming conventions. From an attacker's point of view, the e-mail user naming convention being the same as the user name logon is having half the problem solved for a successful attack.
Some Web sites permit an unlimited number of failed sign-on attempts without being locked out. The vulnerability in this flawed practice is that user accounts can be compromised via brute-force attacks targeting the Web site's password entry.
Brute-force attacks are either manually or automatically performed where alphabetical and numerical combinations are tried as data entries to gain entry. From a preventive control stance, the sign-in policy should be that the user is locked out for a specified time after three failed sign-on attempts.
| Experience Note | Remember, even this policy is not without a threat potential in that an attacker can target the sign-on with incorrect data entry and lock out a legitimate user when she attempts entry. Having a viable and acceptable user reactivation policy is an important aspect of this preventive control. |
There is a useful password-guessing tool to be found at www.tlsecurity.net/windows/cracker/webcracker.htm. This tool will automatically brute-force passwords in HTTP basic authentication and form-based authentication. Auditors should attempt to gain entry through brute-force methods as a means of testing entry security.
Another method that may have some success in defeating brute-force entry tools is to avoid direct linking to the sign-on function. For example, Web pages found behind the sign-on function should have a referrer field where the originating Web page of the user is checked against the allowed Web page URL, uniform resource locator.
Another method defeating some attacks is the error message, "inactivity timeout." This action causes the user's session to be terminated after a predefined period of inactivity. Auditors may test and verify this procedure by opening a Web page session in a sensitive area such as an E-commerce site where financial or personal information is collected. The server should terminate the session after predetermined period of user inactivity. This step prevents someone from hijacking the user's session.
More Unexpected User Input
There are a variety of ways that user input can be different from what was anticipated by the Web page developers. The size of the input can be too large, or too small. The input's content can be inappropriate in that alternate characters or executable scripts may be used causing the server to execute the input. Developers should incorporate user input screening in their programming routines. These are the types of input that should be filtered:
-
Metacharacters are special characters that represent something other than what they are themselves. For example, the ; (semicolon) is a command separator and the ? (question mark) is a match for a single character.
-
HTML delimiter characters such as "<" and ">".
-
Path redirection such as "/../" or ".." indicate the user is attempting to access the directory structure outside the Web server's Web page. These are known as regular expressions and must be screened before being processed by the server.
| Experience Note | User input must always be screened with all improper input denied. |
Overflow Vulnerabilities
Improperly validated user input to the Content-Type header can cause a buffer overflow condition. As a result of nonvalidated user input, excessive data copied onto the data stack can overwrite critical parts of the stack frame such as the calling function's return address, potentially permitting remote code execution with root privileges on the Web server. It is important for auditors to determine if user input is checked for correctness and any input other than the expected input merely returns an error message.
Additionally, it is important that not only user-supplied input is screened and verified, but everything coming from the user's browser to the Web server should be filtered. Users can put executable code within the URL address and without proper filtering, it is possible that user input may be executed by the server.
