Introduction

Do you develop web centric applications? Are you developing an enterprise software solution? Is your application n-tier? Do your software components collaborate from different machines? Are you worried about whether your application is secure? Do you want to know how the external auditors hired by your client certify your app to be secure? Are you into Quality Assurance and need to make sure whether the app you are testing is secure?

Well, this article is here to answer these questions. I have tried to be less verbose, so that after a quick read you will be aware of the most important concepts about this subject.

Part I - Make your application secure

Guard against malicious input

SQL injections: If the queries inside your code execute directly against the user input, the user can provide malicious input which can do nasty things with your database. For example a user types �A ; DELETE * FROM VENDORS� in the vendor name UI field. Your code will execute something like �SELECT * FROM VENDORS WHERE VENDORNAME = A ; DELETE * FROM VENDORS�. The solution is to use validated data and/or using parameterized queries.

• URL tampering: Passing things like User ID through URLs may make your life easier. However keep in mind the consequences if a user puts in the admin ID instead of his own and proceeds using the system.
• Error prone input: Always validate the user input to verify that it�s within the boundary conditions and is void of any special characters which you can�t process.
• Malicious scripts: If your system involves HTML upload from user make sure that it does not contain any scripts. The best way is to strip any SCRIPT blocks from such input.
• Repeated requests: Put a limit on your server on how fast and how many requests it can accept from one client. This guards against DOS (Denial of service) attacks wherein a particular client repetitively requests your server until it is resource starved and eventually dead.

Secure access to the application

The access to each module or page of your application should be authenticated. For example: a user should not be able to just specify a URL and access a page directly. You can choose from various authentication mechanisms like Windows authentication, Active directory, Digital Certificates or go ahead and implement your custom authentication logic.

Encrypt sensitive configuration data

Most people use XML files, registry entries or plain old text files to store CONFIG related info. It should however be kept in mind that the CONFIG data is easily accessible to prying eyes. If you are storing database username passwords or any such sensitive data in these files or the registry, please encrypt it.

Security of the persistent storage

The intermediate (cache) and final data storage files that your app might be generating must be stored inside folders which have appropriate access rights. For example: you can make the folder accessible only to the administrator and run your app with the administrator account so that it can access the folder but nobody else except the admin can touch it.

Data on the wire

For web based systems HTTPS can ensure that the data being transmitted to the client browser is encrypted so that someone can�t just sniff your packets and get access to the data. All web based systems use URLs to pass application flags, IDs and sometimes small footprint data like user name. Avoid using any such human readable data in the URL. Encrypt the URL so that a user can�t just change a parameter in the URL and gets his hand on someone else�s data.

Enforce a strong password policy

If your app enforces the following password policies, there are chances of a smart user looking into his boss' private data:

• Strong passwords: at least 6 characters long and alphanumeric.
• Restrict failed password attempts to 3 to 5.
• Password expiry: make sure users change their passwords periodically.
• Don�t give the hacker a clue: for failed authentication give an error message like �Invalid credentials�. Don�t hint whether the username or the password was wrong.

Map user session to IIS user session

After your application session expires after a user logs out, make sure to clean the IIS session too and vice versa.

Limit the processing to something realistic e.g. large searches

If your app has mechanisms like search where the number of results can potentially be very large, it is a good practice to guard your server with some kind of upper limit. For example you can limit your searches to return only 100 items from the result set at a time. This will save your server boggled down for a single user.

Auditing and logging

Well, this is obvious but often not carefully done. Do audit all the security related operations and provide basic reports for the admin to monitor. This will help find out the mischief early. Also log information regarding crashes/exceptions along with the corresponding user input. In case of malicious entries, this will enable to resolve the issue faster.

Beware of buffer overruns

If you are not working in a managed environment like .NET or Java, you might run into buffer overruns. This happens when you write beyond your array boundaries or to an illegitimate memory location. This may cause corruption of the data in your process memory which can either result in a crash or security vulnerability.

Part II - Make your host secure

• Ensure only the required services are started on your host machine. Run programs and services with specific access privileges.
• Protect shared folders: Make sure your shared folders are allowed to be accessed only by specific users.
• Patches and updates: Do them frequently to keep your OS and OS services free from vulnerabilities.
• Do not encourage default credentials: Enforce your client to disable or password-protect default accounts. For example SQL Server sa user. Request the customer to use custom configured authorizations.
• Stop what is not being used. Disable all unused services like Indexing, Telnet, SMTP, FTP (IIS specific) etc. from your OS box.
• Secure the virtual directory. Set the most stringent permissions on the virtual directory. For example if a virtual directory is storing only htm pages, restrict it to only the read access. Organize the folder structure such that items with similar access levels are clubbed together. Start with only read access to the top folder, and give specific write/execute permissions only where it is necessary.
• Understand that the web page scripts will be executed under the access privileges of the IUSR_MACHINENAME user, so give him only the necessary rights over the necessary folders.

Part III - Make your network secure

Ban all but the valid

Use the firewall configuration to let only those IP addresses connect to your Web Server / App Server machine which are legitimate. Keep only the valid ports open and disable all others.

Firewall security and DMZ configuration

Use the firewall to close all inbound and outbound unused ports. If you must expose a web server use the DMZ configuration wherein say only HTTP/FTP access is allowed to the web server machine and from the WS machine only your app port access is allowed inside the network.

Conclusion

If you follow these guidelines and follow good coding practices, securing your application is fairly straightforward. Depending upon the type of your application (for example utility v/s banking) you can fine tune what all you need to do.

If you found this article useful, you will also find this excellent article helpful: Improving Web Application Security: Threats and Countermeasures.