Hacker Protection for Your Web Applications
By Caleb Sima founder and CTO of SPI Dynamics
Monday, 24 October 2005 10:23 EST
Your Web applications can be the most important and most vulnerable entry point into your organization, and, as such, ensuring adequate hacker protection in your Web applications can be critical.
A Web application not only includes the code that creates your Web site, but also the architectural components necessary to make a Web site available and useful to the public – both of which can make a Web site vulnerable to attacks like SQL injection or cross site scripting (XSS). When considering hacker protection for your Web applications, you must account for all the components that work together to create a Web site, not just the visible face presented to the world at large.
In the past, the majority of security breaches occurred at the network layer of corporate systems, so most corporations focus hacker protection measures at the network layer. Today, however, hackers are using vulnerabilities like SQL injection and XSS to manipulate Web applications inside the corporate firewall, enabling them to access and sabotage corporate and customer data. Given even a tiny hole in a company’s Web application code, an experienced intruder armed with only a Web browser and a little determination can break into most commercial Web sites by exploiting common Web application vulnerabilities like SQL injection. While corporations rush to develop their security policies and implement even a basic security foundation with hacker protection at the network layer, the professional hacker continues to find new ways to attack.
Since the Web’s inception, there have been numerous applications written, and most people trust that these applications are built with hacker protection in mind. Unfortunately, software companies do not produce bug-free applications. Application code is both large and complex, and human error is part of the development process. As long as you have good developers creating the right applications, you assume they are strong and secure, without vulnerabilities like those used for SQL injection attacks. But it is important to remember that all applications are written with functionality and technical requirements in mind, not security or hacker protection.
The evidence is significant: an estimated two-thirds of all security breaches today are due to vulnerabilities within the Web application layer, the most common of which are SQL injection and XSS vulnerabilities. For far too many development professionals, Web application security only consists of producing applications that are functional and stable, not building hacker protection into the code or checking for SQL injection vulnerabilities. As long as the site remains accessible, then everything is functioning within accepted operating parameters. When marketing, sales, and the customer base are satisfied, hacker protection tends to be of little or of no concern. That application may be functioning properly, but it is not necessarily functioning securely. Ignorance can be bliss, but knowledge can come with a painfully high price in terms of negative publicity, lost revenue and lost customer confidence.
Coping with the potential impact of hackers and enacting adequate hacker protection requires a new understanding of how they operate. A common misconception is that hackers are content with defacing your Web site. This is true for a small percentage of hackers who gain self-esteem, publicity or a sense of control from publicly humiliating a company. For many hackers, it is simply a matter of the challenge. The old adage “because it’s there” can apply to hacker motivation as well. Hackers are methodical and understand the significance of Web application vulnerabilities like SQL injection and XSS.
Most hackers are using these “out of the box” security holes, of which SQL injection and cross site scripting are just a couple, to gain escalated privileges or execute commands on a company’s server. In these cases, hacker protection can be as easy as checking the software’s configurations. Simple misconfigurations of off-the-shelf Web applications and in-house produced applications leave gaping security vulnerabilities in an unsuspecting company’s Web site.
So how does a hacker discover Web applications that have not enacted adequate hacker protection? Very easily. A hacker starts by running a port scan to detect the open HTTP and HTTPS ports for each server and retrieving the default page from each open port. He or she then identifies the type of server running on each port, and each page is parsed to find normal links (HTML anchors). This enables the hacker to determine the structure of the site and the logic of the application. Then, the attacker analyzes the found pages and checks for comments and other possibly useful bits of data that could refer to files and directories that are not intended for public use. The hacker goes through a testing process for each of the application scripts or dynamic functions of the application, looking for development errors like SQL injection and XSS vulnerabilities that will enable a person to gain further access into the application. If the Web application has been developed with hacker protection in mind, these vulnerabilities will not be available to exploit.
When the hacker has identified every bit of information that can be gathered by passive (undetectable) means, he or she selects and deploys attacks. These attacks center on the information gained from the passive information gathering process. After all of these procedures, the hacker begins the pillaging by attacking each Web application identified as having inadequate hacker protection during the initial review of your site. The results of the attack could be lost data, content manipulation, or even theft and loss of customers. The average corporation does not have the mechanisms to detect such attacks and can spend significant resources just trying to diagnose the implications of an attack. For companies that have failed to invest in hacker protection, the potential for loss is significant. A hacker could easily copy sensitive corporate information, such as proprietary customer databases or records, and disseminate that information to competitors, or even to the general public, without your knowledge.
Following are detailed examples of both SQL injection and cross site scripting, which are common Web application hacking methods that can allow intruders to compromise the confidentiality, integrity and even functionality and availability of a company’s network data when no measures are taken towards hacker protection in the application layer.
SQL Injection
SQL injection allows an attacker to gain access to a backend database through the trusted Web site. If the Web site has not invested any time in hacker protection and contains development errors, an attacker can format a Web request so that an SQL statement will get ‘piggybacked’ onto the real request from the Web application, and the attacker’s request will get executed. This occurs because the input from the user is ‘trusted’ and not filtered properly. To ensure complete hacker protection from SQL injection, any type of request to your SQL server needs to be filtered before it is executed. If fully exploited, SQL injection can lead to an attacker downloading the entire backend database to the local machine.
Step 1. Open the Web site in a browser.
Step 2. Mouse over the links of the Web site with your cursor while paying attention to the bottom status bar. You will notice the URLs that the links point to. Try to find a URL with parameters in it (Ex. http://www.site.com/articleid.asp?id=42). Most SQL injection problems are present when the file extensions are “.asp” or “.cfm”. When trying to test a site for SQL injection vulnerabilities, look for these files specifically.
Note: If you don’t see any URLs in the status bar, then just click on links, and watch the address bar until you find a URL that has parameters.
Step 3. Once a URL with parameters has been found, click the link, and go to that page. In the address bar, you should now see the URL that was seen in the status bar.
Step 4. Here is where the actual testing for hacker protection takes place. There are 2 methods for testing script for SQL injection. Be sure to test each parameter value one at a time with both methods.
Method 1. Go to the address bar, click your cursor, and highlight a parameter value (Ex. Highlight the word value in “name=value”), and replace it with a single quote (‘). It should now look like “name=’”
Method 2. Go to the address bar, click your cursor, and put a single quote (‘) in the middle of the value. It should now look like “name=val’ue”
Step 5. Click the ‘GO’ button. This will send your request to the Web server.
Step 6. Analyze the response from the Web server for any error messages. Most database error messages will look similar to the examples below:
Example Error 1:
Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '51 ORDER BY some_name'. /some_directory/some_file.asp, line 5
Example Error 2:
ODBC Error Code = S1000 (General error)
[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended
Step 7. Sometimes the error message is not obvious and is hidden in the source of the page. To look for it, you must view the HTML source of the page and search for the error. To do this in Internet Explorer, click the ‘View’ menu, and select the ‘Source’ option. This will cause Notepad to open with the HTML source of the page. In Notepad, click the ‘Edit’ menu, and select ‘Find’. A dialog box will appear that will ask you to ‘Find What’. Type the phrase ‘Microsoft OLE DB’ or ‘[ODBC]’, and click ‘Find Next’.
Step 8. If Either Step 6 or 7 is successful, then the Web site is vulnerable to SQL injection.
Cross Site Scripting
Cross site scripting (also known as XSS or CSS) occurs when dynamically generated Web pages display input that is not properly validated, an important aspect of hacker protection. This allows an attacker to embed malicious JavaScript code into the generated page and execute the script on the machine of any user that views that site. Cross site scripting could potentially impact any site that allows users to enter data. This
vulnerability is commonly seen on the following:
Search engines that repeat back the search keyword that was entered; Error messages that repeat back the string that contained the error; Forms that are filled out where the values are later presented to the user; Web message boards that allow users to post their own messages.
Putting hacker protection in place to prevent cross site scripting is relatively easy and well worth the effort. An attacker who uses cross site scripting successfully might compromise confidential information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end user systems.
Step 1. Open the Web site in a browser
Step 2. Browse the Web site for areas that accept user input and will return back what you typed in. The most common locations for these areas on Web sites are search engines and login forms.
Step 3. Once you have located a search engine or login form, enter “test” into the search field or login name, and submit the request to the Web server.
Step 4. Look for the Web server to respond back with a page similar to
1.“Your search for ‘test’ did not find any items”
2.“Your search for ‘test’ returned the following results”
3.“User ‘test’ is not valid”
4.“Invalid login ‘test’”
If the word ‘test’ appears in the results page, then an entryway for cross site scripting has been found.
Step 5. To test for hacker protection against cross site scripting attacks, input the string “” without quotes as done with “test” in step 3. Submit the request to the server.
Step 6. If the server responds back with a pop-up box that says “hello”, then the Web site is vulnerable to cross site scripting.
Step 7. If Step 6 fails, and the Web site does not return a popup box, click the ‘View’ menu in IE, and select the ‘Source’ option. This will cause Notepad to open with the HTML source of the page. In Notepad, click the ‘Edit’ menu and choose ‘Find’. A dialog will appear that will ask you to ‘Find What’. Type the phrase “” and click ‘Find Next’. If the text is found, then the Web server is vulnerable to cross site scripting and requires implementation of hacker protection to prevent these attacks.
Once you enter the arena of e-business, your short-term business prospects and long-term viability and shareholder value all become directly linked to your e-business strategies and ability to manage the risks of doing business online, which include hacker protection to prevent attacks like SQL injection and XSS. You must simultaneously protect information while opening your doors to outside partners, customers and employees. The performance and security of your systems, as well as those of your third-party partners, are critically important to long-term success.
Companies must view their Web applications as a portal to corporate assets and hence, implement the necessary hacker protection and security procedures to ensure that those assets are secure from malicious attacks like SQL injection and XSS. This includes defining security and hacker protection as part of both the functional and technical requirements of an application. To achieve a greater level of application security, mature development practices that focus specifically on Web application security and hacker protection at the application layer need to be implemented. Companies who are vigilant and proactive in their approach to application security are better protected, and, in the long run, these companies enjoy a higher return on investment for their e-business ventures.
|
|
GFI LANguard Network Security Scanner - Is your network open to attack? Find out with the
#1 sold network security scanner: GFI LANguard Network Security Scanner! Download your FREE trial version today.
Visit GFI Security Software page for more information.
IT-Gear.com - Weblog dedicated to everything concerning IT tools and services.
Latest News
SECUDE appoints Open-Source specialist as Linux Expert
02.11.06 SECUDE IT Security GmbH has confirmed the appointment of Felipe Rodriguez, a Linux Kernel contributor and owner of the Open-Source project MGSTEP, as its Linux Expert.
Increased Spam Fuelled Through Botnet Activities
02.11.06 MessageLabs, a provider of integrated messaging and web security services to businesses worldwide, has announced the results of its Intelligence Report for October 2006.
How to keep your VoIP net safe
30.10.06 One of the major challenges in implementing a converged network is having a coherent security policy for the management and control of a system that is carrying voice, video and data.
User tricks, security treats
30.10.06 Thirteen malevolent spirits may haunt the halls and cubicles of your company, and if you're going to scare them into security compliance you may need to get a little bit spooky yourself.
10 Steps to More Secure Wireless
27.10.06 We have all heard about the stories of spammers using open home wireless networks to fill the net with junk mail.
BT acquires Counterpane Internet Security
25.10.06 BT has announced that it has acquired Counterpane Internet Security, a provider of managed networked security services, as part of its strategy to expand and develop its global professional services capabilities.
Perdemia updates Permission Analyzer
25.10.06 Perdemia has upgraded Permission Analyzer, a powerful Windows administration tool that quickly determines whether the system access permissions are properly set, need to be changed, or have been altered by people who are not authorized to make changes.
Mac OS Bluetooth exploit - Inqtana.d
25.10.06 Inqtanad is a proof-of-concept exploit, which has not yet been seen in the wild, that is installed on a Mac OS X computer via Bluetooth from a computer or PDA running a Linux system.
|
|
