Securing Web Portals

By Michael Leach Cubic Compass Software, Founder Deploying web portal applications over the Internet can be a challenging and intimidating experience. Within seconds of connecting to the Internet, portal servers are immediately bombarded with requests from unknown sources with potentially malicious intent. With a basic understanding of the types of attacks portals are subjected to and some knowledge on how to counter these attacks, you can keep your portal highly secure and available.

Using chess as a metaphor, you can think of securing your portal as a chess board with layers of infrastructure between the attacker and your organizations data. Internet attacks attempt to penetrate and advance through several layers consisting of network infrastructure, operating systems, application servers, portal servers and applications, and finally, your precious King, the data. In the case of securing an Internet portal, the end game is not necessarily to kill the King. Once attackers have successfully breached any layer, they are often content with moving laterally within an organization to other computing assets. IT Managers must be aware of the various types of attacks and demand that all products used in an Internet portal solution address these threats out of the box.

Types of Portal Attacks

Physical Attacks
Physical attacks are attacks against networks, phone lines, wires, and computers that attempt to physically disable a portal server.

Syntactic Attacks
Syntactic Attacks are the ones we see in the news daily and that have spawned an industry of virus protection software and frequent operating system updates and patches. Syntactic attacks exploit vulnerabilities in software products, protocols, and cryptographic algorithms.

Indiscriminate and Intentional

A vast majority of attacks today are syntactic and can be broken down further into indiscriminate and intentional attacks. Most attacks are indiscriminate and are the result of computers being compromised by a viruses or worms which have been programmed to propagate themselves by actively seeking other vulnerable computers. Some indiscriminate attacking viruses, worms, and scanners have the ability to notify a person once a computer has been compromised. At this point, a hacker may initiate an intentional attack against the computer. An intentional attack is what is commonly depicted in movies and TV shows with someone sitting down at a computer, gaining access to a computer, and perusing its contents. Some attacks, such as in a Denial of Service attack, use a combination of indiscriminate and intentional attacks by instructing several zombie servers (also called bot nets) to focus on a single web site.

Semantic Attacks
Semantic attacks target the way humans assign meaning. These include fake emails posing to be from eBay and luring victims to a web site in hope that they will divulge personal information.

Preventing Attacks
With a basic understanding of the types of attacks, you can then begin to focus on securing your Internet portal against these attacks.

Physical Security
Host the portal only if it is considered a core competency The Internet Service Provider and data center markets thrive on providing value by offering physical security and reliability. We recommend that organizations with mission critical portal requirements do not host the portal themselves unless data center operations are considered a core competency of the organization. See the resources section of this article for detailed checklists and plans for securing a data center.

Securing the Network

Limit the number of ingress ports By default, portal web servers listen on either port 80 (http) or port 443 (https) for page requests. Firewalls should be configured to only allow requests on these ports. For remote administration, an additional port may need to be opened to allow for a secure VPN tunnel. If your portal server is supporting multiple services, such as an email or FTP server, then vulnerabilities in these protocols then become vulnerabilities in your portal.

Use Non-Standard Ports Consider hosting your web server on a non-standard HTTP/HTTPS port. An example would be redirecting requests for http://www.domain.com to http://www.domain.com:8080/. For an added layer of security, some portal administrators choose to configure their web server to listen for page requests on non-standard ports, such as 81, 8080, or 8090. This approach wont make your network more secure, but it will avoid the bots and viruses that are programmed to do their work against only port 80. Use Egress Filtering Filtering inbound packets on a firewall is a fundamental first step. But responsible servers on the internet should also filter the outbound packets as well so that they cannot be the source of more attacks. For example, if your portal server were to become compromised because of malicious inbound packets, you still may be able to prevent a worm from propagating by filtering your outbound traffic. Packets from other addresses or ones that are attempting an outbound FTP connection are examples of traffic that should never leave your portal server.

Securing the Operating System

Keep patches up to date. Within seconds of connecting a portal to the Internet, it may become bombarded with potentially harmful packets. Without up to date patches, the chances are extremely high that the server will become susceptible to a buffer overflow attack. To prevent this from happening, the portal server should be patched before connecting to the Internet. Afterwards, subscribe to a trusted active patching service. These resident patching services are a type of spyware that typically monitor the OS manufacturers or distributors servers for up to date patching information. Depending on your level of comfort, you can configure these services to download and install patches on their own or have them notify you to take action yourself. Synchronize Network Security Settings The port settings defined in Securing the Network must also propagate to the operating system. Configure the port that the portal web server will listen on as well as any additional ingress/egress filters provided by the OS.

Limit the number of admin accounts Limit the number of user accounts on the OS that have root access and privileges. Use Prudent Password Management Occasionally change all admin passwords. Use alpha-numeric combination passwords that do not appear in dictionaries. Limit the services and applications Even if a portal server is secured at all layers in the portal architecture, it is still possible for hackers to gain access through an application or service running on the portal server. Frequently examine and question all applications and services running on any secure server. Future worms and viruses will typically exploit RPC (Remote Procedure Call) services that are harmlessly running today.

Securing the Application Server

For the purposes of this discussion, the application server is considered to be any service that processes or redirects HTTP requests. A basic web server will listen for requests for common World Wide Web pages ending in HTM, HTML, JPG, or GIF. The web server simply fetches these pages from the local file system and streams them back to the requestor. An application server differs in that it listens for requests for files ending with a specific extension, such as .ASP, .JSP, .CGI, .PHP, or .CFM, and then executes instructions embedded in those pages (also called scripts) to render a response. Additional information is often passed to these scripts in the form of CGI parameters. As application servers become increasingly complex, they also become susceptible to new types of attacks. Tips for securing your application server include: Maximize the use of Portals executing on virtual machines Buffer overflow attacks take advantage of application server environments where there is little or no memory management. They send requests to the portal server that overburden the application, which then takes control of the machine. Secure portals should leverage technologies such as JSP or ASP.NET that run on virtual machines to ensure the portal applications they host are free from memory leaks and not prone to memory related crashes. Portals running on application servers created using languages such as C, C++, or PERL, while feature rich, present a risk because of their lack of enforced memory management.

Limit the Permissions of the Web Process User Application servers typically run as processes using the access credentials and permissions of a named user on the server. If your portal does not need the ability to physically delete files on the portal server, then do not allow your application server to run under an admin or root user account. Review the matrix of access controls granted to the application server process and be vigilant in removing unnecessary permissions. Use Secure Sockets Layer Consider encrypting all communications between the portal and browser by applying an SSL certificate to the web server. SSL must be used whenever a portal collects secure information, such as credit cards or personal health related information. Maximize Use of Logging Enable all web server and application server logs and configure them to provide the most verbose information as possible. Audit logs are a critical device for monitoring and learning from suspicious activity.

Securing the Portal

Encrypt or Hash Account Passwords A portal administrator, or anyone gaining physical access to a portal server, should not be able to read account passwords in the portal database. Because the majority of information leaks and system compromises occur from within, it is imperative that account passwords be stored in encrypted or hashed form. 3 Strikes Youre Out Policy Successive failed sign on attempts to a single account within a short time period is an indication of a dictionary attack. Implement an X strikes youre out for Y minutes policy, where X is the maximum number of failed sign on attempts and Y is the number of minutes the account is suspended. 2 Factor Authentication Portals may authorize access to users based on a number of factors: o Something you know (Password, PIN) o Something you have (Smart card, USB key) o Something you are (Fingerprint, Retina scan) Most web portals are single factor: You only need one of the above (e.g. password).

Consider issuing smart cards or USB keys to portal members to increase portal security. Multi factor authentication can be expensive to outfit every client machine with the required authentication hardware. Use the Model-View-Controller Design Pattern To truly secure a portal, the portal must limit the number of pages attackers have access to by filtering all requests through a centrally managed gateway. For this reason, most portals and content management systems implement the Model-View-Controller (MVC) design pattern, which limits the portal application to a single web page that manages all security and dynamically loads portlets. Role Based Security Role based security enables or disables access to portal content based on the users role. A common portal architecture used in Employee Portals is to inherit the role based security from the operating system, such as from an LDAP directory or Microsofts Active Directory. Extranet, Internet, and content management portals typically implement their own layer of role-based security because using operating system client licenses are cost prohibitive for this type of application.

Example of Role Based Access Control list.

Rule Based Security Rule based security enables or disables access to portal content based on rules. An example of rule based security is providing access to 401K enrollment information to all users in the Employee role who have been employed for more than 6 months. Filter Search Results A search for Employee Salaries on an Intranet portal should produce different results for a Human Resource Director and a Customer Service Representative. All content should be protected by the portals role or rule-based security model and search results must filter based on this model. Maintain Detailed Audit Trails of Portal Events A portal should log every event. Some of this information may be redundant with the web server logs, but when using the MVC design pattern, the web server logs are simply full of IP addresses requesting a single web page with varying CGI parameters. Additionally the W3C logs contain lots of noise data, including requests for images and style sheets. The portal log should maintain audit trails of every event (also called click streams), to include the UserID, portal, portal object, event type, date/time, IP Address, and any other descriptive information. Give yourself opportunity to pursue legal course of action. Most hackers believe they are completely anonymous when conducting intentional attacks.

Auditing a portal click stream using an analysis tool

Implement a portal governance model. Define and strictly enforce who has permission to create, modify, add, or delete all portal content. Define content publishing process workflows that fit naturally within the organization. Educate the portal members. Prevent phishing by educating portal users that they will never be asked for their passwords via email. This can be accomplished via occasional reminders in newsletters and in online portal instruction content.

Securing the Portal Applications (Portlets)

Authorize All Server-Side AJAX Calls The next major wave of web application attacks and compromises will occur through AJAX gateways. AJAX is a programming technique that allows web applications to send requests directly to web servers from a browser using Javascript. The result is dynamic page updates and less page refreshes.

It is very easy to reverse engineer AJAX calls because the source code is openly available and embedded in web pages. Hackers are looking for careless web applications that allow XmlHttpRequests to pass straight through to a database with authorization. All AJAX requests must pass through the same authentication and authorization processes used in web page rendering. Leverage portal resources for security Do not defeat the purpose of securing a portal server by then allowing portal applications (also called portlets) to override these settings. Whenever possible, portal applications must defer to the global portal settings and security infrastructure when dynamically rendering secure content. Prevent Script Attacks Change all < characters to &lt; and > characters to &gt;. These ampersand escape character codes are defined in the HTML 4.0 standard and represent less-than and greater-than. Other character sets, such as UTF-7, have alternate encodings for < and >, so to truly prevent this type of attack the server must define the encoding towards the top of each portal page using the following:

<HTML> <HEAD> <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <TITLE>HTML SAMPLE</TITLE> </HEAD> <BODY> <P>This is a sample HTML page </BODY> </HTML>

Use Stored Procedures. Do Not Trust CGI Parameters Explicitly Portlets that dynamically construct SQL statements to execute database transactions are highly susceptible to attacks that allow portal users to craft web form inputs that have undesired consequences. For example, the following statement dangerously executes a SQL statement based on a value received from the browser: string sqlStatement = SELECT * FROM Customers WHERE CustomerID= + Request.Params[CustomerID]; An attacker can corrupt this portal application by simply entering (DELETE FROM Customers) as the CustomerID CGI parameter on the web browser address bar.

Instead, portlets should pass this parameter to a database stored procedure which will enforce strict typing of parameters and will not allow the modification of the intended SQL statement.

Securing the Data Sources

Define portlet access permissions at the data source. A common flaw in many portlets is allowing them to query remote data sources by establishing connections using database System Administrator (sa) credentials. If the portlet is only reading from a data source, then force the portlet to establish a connection with the credentials of a database user account with only SELECT permissions against the data source. For portlets that allow users to view, add, and update records, consider creating a database user account that does not have DELETE permissions. Impersonation is another security approach that propagates the permissions of the currently authenticated user to the database.

Conclusion
This paper provides a basis for categorizing types of attacks on Internet portals and some tips and suggestions for defeating these attacks. Internet security is a constantly evolving practice that requires vigilant dedication to monitoring attack trends and aggressively taking measures to prevent them. While there is much an IT Professional can do to protect their portals against physical and syntactic attacks, there is little they can do against semantic attacks, except to educate their portal members and IT customers. Security is a cross-functional responsibility and groups, such as Marketing and Human Resource, must share in the responsibility of educating customers, employees, and partners. As Internet portals increasingly become the primary gateways for conducting business, security must become a cultural principle and value for an organization to survive.

References
The following resources have contributed greatly to the body of knowledge on Internet security and the content in this article. Data Center Physical Security Checklist http://www.giac.org/practical/GSEC/Sean_Heare_GSEC.pdf CERT: Overview of Attack Trends http://www.cert.org/archive/pdf/attack_trends.pdf Foil Semantic Attacks http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/semanticattacks.html Bruce Schneier on Semantic Attacks http://www.schneier.com/crypto-gram-0010.html

Contact
Michael Leach is the Founder and CEO of Cubic Compass Software; a provider of enterprise portal software and solutions. For comments related to securing Internet portals, Mr. Leach can be contacted at: mike@cubiccompass.com 1-503-245-7654 Cubic Compass Software http://www.cubiccompass.com