Best practices for building and configuring a secure UNICOM Intelligence website

This white paper provides you with the best solutions for building and configuring a secure UNICOM Intelligence website. UNICOM Intelligence uses the IBM Rational Appscan application for the purpose of detecting security vulnerabilities. AppScan tests against several different standards and guidelines (for example, WASC and OWASP Top 10). As examples, AppScan is used to test UNICOM Intelligence for the following security vulnerabilities:

When configuring UNICOM Intelligence, operating system, and associated applications, see also Security considerations.

Description: Web applications often use databases at the backend to interact with the enterprise data warehouse. The de facto standard language for querying databases is SQL (each major database vendor has its own dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an SQL query, which is then sent to the backend database. The query results are then processed by the application and sometimes displayed to the user.

This mode of operation can be exploited by an attacker if the application is not careful enough with its treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when incorporated into an SQL query, changes the original syntax of the query into something completely different. For example, if an application uses user's input (such as username and password) to query a database table of users' accounts in order to authenticate the user, and the attacker has the ability to inject malicious data into the username part of the query (or the password part, or both), the query can be changed into a different data yanking query, a query that modifies the database, or a query that runs shell commands on the database server.

Resolution: To protect your application from SQL injection, perform the following steps:

Follow these guidelines to constrain input

The following code shows how to use the SqlParameterCollection when you call a stored procedure.

using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand cmd = connection.CreateCommand();
cmd.CommandText=”RemoveUserById”
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@id", SqlDbType.VarChar, 100);
cmd.Parameters["@id"].Value = ID.Text;
cmd.ExecuteNonQuery();
}

The following code shows how to use the SqlParameterCollection when building dynamic SQL.

using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand cmd = connection.CreateCommand();
cmd.CommandText=”Delete From Users Where id=@id”
cmd.CommandType = CommandType.Text;
cmd.Parameters.Add("@id", SqlDbType.VarChar, 100);
cmd.Parameters["@id"].Value = ID.Text;
cmd.ExecuteNonQuery();
}

The following code shows how to use the SQL parameter in .mrs.

Dim connection, cmd
Set connection = CreateObject("ADODB.Connection")
connection.Open(connectionString)
Set cmd = CreateObject("ADODB.Command")
Set cmd.ActiveConnection = connection
cmd.CommandText = "Delete From Users Where id=?"
cmd.Parameters[0] = id
cmd.Execute()

To avoid SQL injection in web surveys, use SQL parameters in your .mrs.

Description: Cross-site scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

Resolution: For UNICOM Intelligence Web applications, the two most important countermeasures to prevent cross-site scripting attacks are:

Refer to Preventing cross-site scripting in text responses for details on avoiding cross-site scripting attacks in IOM.

Description: Cross-site request forgery (CSRF) is an attack that allows a hacker to perform an action on the vulnerable site on behalf of the victim. The attack is possible when the vulnerable site does not properly validate the origin of the request.

Resolution: ViewState can be used as a CSRF defense in ASP.net, as it is difficult for an attacker to forge a valid ViewState. It is not impossible to forge a valid ViewState since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each ViewState unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the ViewState to protect against spoofed post backs, add the following in the OnInit virtual method of the page-derived class; if your web page is not inherit from the page-derived class, you must explicitly add the following code in your own web page.

Description: During the application test, it was detected that an unencrypted login request was sent to the server. Since some of the input fields (for example, usernames, passwords, email addresses, social security number, and so on) used in a login process are personal and sensitive, it is recommended that these fields are sent to the server over an encrypted connection (SSL for example).

Any information sent to the server as clear text might be stolen and used later for identity theft or user impersonation.

Resolution: Configure your website to use SSL. See Setting up your website to use SSL for more information.

Description: A brute force attack is an attempt by a malicious user to gain access to the application by sending a large number of possible passwords and usernames. Since this technique involves a large amount of login attempts, an application that does not limit the number of false login requests is vulnerable to these attacks. It is highly recommended that you restrict the number of false login attempts allowed on an account before it is locked.

Resolution: UNICOM Intelligence restricts the number of false login attempts allowed on an account before it is locked. Two settings are added to the registry under:

This setting defines the number of false login attempts allowed on an account before it is locked, the default value is 3 (after 3 invalid password attempts, the account is locked out).

This setting defines the default lock out time range for a locked user account. The time unit is measured in hours, and the default value is 2 (a locked user account can be re-login after 2 hours).

Description: Phishing is a general term for attempts to scam users into surrendering private information that can be used for identity theft. An HTTP parameter was found to hold a URL value and cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker can successfully launch a phishing scam and steal user credentials. The fact that the server name in the modified link is identical to the original site helps the attacker by giving his phishing attempts a more reliable appearance.

Resolution: UNICOM Intelligence includes the configuration setting SPSS_TrustedDomain to avoid this issue. For more information, see Settings for the Login component.

Description: The Web server is configured to allow one (or more) of the following HTTP methods (verbs):

These methods might indicate that WebDAV is enabled on the server, which could result in unauthorized user exploitation.

Resolution: This issue can be avoiding by either disabling the WebDAV service or disallowing the unneeded HTTP methods (verbs). See the information about WebDav in Installing Internet Information Services for more information.

Description: By default, only the EnableViewStateMAC (Hashing) security measure is used by the .NET framework. If you do not explicitly turn on the encryption option, the ViewState information (the dictionary that stores name/value pairs) and the Controls' state are exposed to the attacker. This might help the attacker learn the application logic, and could reveal sensitive information.

Resolution: Add the following line to the Web.Config file, under the <system.web> element:

Description: The web application has exposed the presence of a directory in the site. Although the directory does not list its contents, the information might help an attacker to develop further attacks against the site. For example, by knowing the directory name, an attacker can guess its content type and possible file names that reside within, or sub directories under it, and try to access them. The more sensitive the content is, the more severe this issue might be.

Resolution: If the forbidden resource is not required, remove it from the site. Or issue a 404 - Not Found response status code instead of 403 - Forbidden. This change will obfuscate the presence of the directory in the site, and will prevent the site structure from being exposed. For more information, see Configuring Internet Information Services to avoid the detection of hidden directories.

Description: The AUTOCOMPLETE attribute was not disabled on forms where sensitive information, such as passwords and user names are entered. For example:

When the AUTOCOMPLETE attribute is not disabled, passwords and user names can be transparently stored by the browser, potentially exposing them to other users of the same workstation environment.

See also the Microsoft MSDN article “Using AutoComplete in HTML Forms”:

An attacker would require local access to the user’s browser in order to exploit this vulnerability. The exposure of this issue was rated as High since users could access the application from shared public Internet terminals (such as an Internet café). Should access to the application be restricted to only authorized and secured workstations, then the exposure would be rated as Low.

Resolution: Disable the AUTOCOMPLETE attribute on the form. For example:

Description: Attackers might try to steal cookies by using a spoofed referrer.

Resolution: UNICOM Intelligence prevents motivated attackers from stealing user cookies by using a spoofed referrer. However, an error might occur when users try to login to UNICOM Intelligence Interviewer - Server Admin: for example, if they use a fully qualified domain name (FQDN) in the address. To avoid this error, you can specify a list of trusted domains: see Adding the domain name to the DPM trusted domain list.