 |
 |
| HOME | ABOUT ME | BIOTECHNOLOGY | ARTICLES | TOOLS | GALLERY | CONTACT |
| DEVELOPER TOOLS ASP Documentation Tool .NET Documentation Tool PHP Documentation Tool SQL Documentation Tool VB6 Documentation Tool Indexing Service Companion The Website Utility TECHNICAL
ARTICLES PHOTO GALLERIES TRAVEL LOG NEW STUFF POPULAR STUFF LINKS
|
Improving ASP and ASP.NET Website Security - Part TwoIdeas for improving the security of ASP and ASP.NET web applications. Part 1 | Part 2 | Part 3 | Part 4 | Part 5Guard web applications against SQL Injection AttacksWhen building a website that connects to a SQL database (i.e. Microsoft Access or SQL Server) it is of crucial importance that care is taken to be aware of SQL Injection Attacks. These typically occur when the website allows the website user to enter content through online forms (particularly textboxes). However, the lack of strong variable typing in classic ASP means that any variable that is retrieved from the user's browser can be vulnerable to being used in a SQL injection attack. At the very least, it would allow the user to perhaps login to a website without needing to know a username and/or password. Depending on the security settings in the website's database, they may even be able to delete data or execute arbitrary system commands on the machine hosting the database server. Classic ASP is particularly vulnerable to SQL injection attacks. For example, a web page that retrieves a particular record from a database table row by retrieving the row's primary key from the querystring can be potentially used in a SQL injection attack. If the user visits a URL, such as http://www.ajobwebsite.com/jobs/showjob.asp?JobID=12227, then they may be able to append a certain sequence of characters to the end of the JobID in order to force a SQL injection attack. Fortunately, this particular SQL injection attack can be mitigated by ensuring that showjob.asp converts the JobID query string parameter to a number by using the Cint() function in VBScript or Math.round() in JScript. Ideally, all user input derived from query string parameters and form fields should be cleansed in order to remove any characters that do not need to be present in a particular variable. For example, a number field should only contain numbers. Using the VBScript Replace function can easily achieve this. Particular care should be taken to remove single quotes or dashes from user input, unless they are specifically needed in a particular variable (for a person's name). Single quotes should also be converted to double quotes before the variable is used in a SQL statement. There are two other ways of minimizing the chance of SQL injection attacks occurring. The first is to use stored procedures to carry out all database queries, rather than constructing SQL statements in the web page itself. The second is to use the ADO or ADO.NET Command object to carry out database connectivity. Finally, on an SQL Server, using a dedicated database user with the minimum set of permissions required will prevent a malicious user from being able to do too much, should they discover a way of performing SQL injection attacks against the database. Clean user input before redisplayingAs described earlier, care should be taken to clean up user input before it is used in SQL queries in order to fend against SQL injection attacks. Unfortunately, similar techniques can be used by malicious users to perform other actions. At the very least these can be a nuisance, but there is potential to perform actions that mislead your website's other users, make it easier to launch cross-site scripting attacks or to launch fishing attempts. Any user input that is gathered by a web application and then redisplayed on a web page should be cleansed before it is displayed on that web page. In particular, care should be taken to remove all of the HTML tags that a user may have entered or, alternatively, all HTML mark-ups should be removed except for a few "safe" tags, such as bold and italics tags and paragraph formatting tags. Particular care should be taken to remove <script> tags entered by the user. Failure to remove script tags will allow a malicious user to run JavaScripts within pages that display their input. This is a particular problem on websites where one user's input is viewable by many people, such as on bulletin boards and discussion forums. At the very least they might cause annoying JavaScript alert windows to appear when someone views a page containing their script input. They could, however, potentially make use of the JavaScript document.location method to cause the user's browser to automatically go to a different URL when they visit your website. To remove all HTML tags from user input, a regular expression substitution can be used, such as the one shown on the VBScript regular expressions page. Alternatively, the user's input can be converted using the Server.HTMLEncode method in classic ASP or the HTMLEncode method of the HttpUtility class in the .NET Framework. This method would prevent any of the user's inputted HTML from being interpreted by a web browser. See the Regular Expressions article for further information about using Regular Expressions in ASP. Regular Expressions are also available in ASP.NET through the System.Text.RegularExpressions namespace. A safer alternative to allowing users to enter HTML is to permit them to use the Bulletin Board Code (BBCode) text formatting system that is commonly used on many web based bulletin boards. There are a number of ASP scripts available that will safely convert BBCode formatting to HTML using ASP. Regularly examine IIS log files for signs of unusual activityIf you have access to your web server's log files then it is extremely worthwhile spending time examining them in order to identify suspicious use. Even if you use a website's statistics analysis application, there is a good chance that irregular behavior will go unreported. This is largely due to the fact that most websites' statistics packages are concerned with analyzing the typical usage of website users, rather than flagging up non-standard website usage. For example, I once worked at a large organization that was periodically experiencing regular surges in the number of website visitors. Although the commercial website's statistics package in use by the organization was able to identify when the peaks in traffic occurred, it took a manual analysis of the IIS log files to discover the cause of the traffic peaks. Although manual examination of web server logs is effective, it is worthwhile investigating the various automatic forensic log tools available. A particularly useful utility is Microsoft's Log Parser. This utility allows any type of log file to be queried by using a standard SQL syntax, making it a powerful tool for extracting, sorting and displaying summaries of activity from web server log files. Log Parser may be obtained from the Microsoft download site. When manually looking at log files, it is also recommended to use a text editor that offers a fuller feature list than the Notepad application supplied with Windows. Two text editors that are particularly good at handling log files are TextPad (http://www.textpad.com/) and UltraEdit (http://www.ultraedit.com/). Both of these editors will open files much larger than those that can be opened in Notepad. They also offer more sophisticated search facilities and allow specific lines to be pasted into new documents. Unfortunately, there don't appear to be any software packages available that will automatically analyze log files in order to identify suspicious activity. To a certain extent this may be because the determined hackers with full access to the compromised system will often modify the log files so that they are undetected anyway. It is, however, possible to obtain Intrusion Detection Systems (IDS) that can be used to identify suspicious activity in near real time. Part 1 | Part 2 | Part 3 | Part 4 | Part 5Useful Development Tools
|
|
| Site Map | All content is © 1995 - 2008 Brett Burridge |
