Introduction Applications often serve as the delivery mechanism through which personal data and other sensitive information is transferred online. Unsecured or poorly written applications can be exploited to bypass security measures or used to transfer information that is easily intercepted. The following guidelines outline several steps necessary for application developers to prevent such abuses.

Federal law, state law and UF policies require protection of personal, confidential and sensitive data.  Some applicable laws and policies are listed below.  Other UF IT policies can be found on the Policies and Standards page.

Defense in Depth Security should be implemented at multiple levels to prevent a breach in one level from compromising the entire application.  Users should be aware of all the techniques discussed in this document and use multiple techniques where possible and appropriate.  See the UF Network and Host Security Standard and Procedures.  Consider access control lists and firewalls for added protection. Methodology, Review and Testing It’s better to avoid security vulnerabilities than to fix them.  Conduct internal peer review or external, third party assessment. Choosing a formal development methodology will impart structure, reduce errors, and encourage review at each stage of development.  Developers must demonstrate compliance with UF Network and Host Security Standard and Procedures.

Automated tools can be used for review and testing, but should not replace manual methods.  Testing should include the following methods:

  • Attempt to impersonate users or servers
  • Attempt to perform fraudulent transactions
  • Attempt to compromise data
  • Attempt to send junk data
  • Attempt to compromise server
  • Attempt a denial of service

General Application Security Data Protection

Auditability and Logs The code itself should be easily auditable.  This includes following proper programming guidelines and documenting code where the intent is not immediately obvious.  Most importantly, however, usage, errors, and abnormal conditions should be tracked with logs that are monitored in some manner.  Watching application logs is one of the best ways to detect a number of different cracking attempts, such as password brute forcing, data injection and other forms of data input validation abuse.  Proper logging will record failures and the error conditions.

Consider archival of the logs for a reasonable length of time to allow comparison of current logs with previous logs.

If the volume of logs generated by an application are prohibitively large, try automating parsing of the logs to prevent the application developer or system administrator from having to review the entire log by hand.  Additionally, coding different verbosity levels within the application for different levels of log monitoring is extremely useful. Data Input and Validation Before working with user input, ensure that it is safe by limiting the allowed characters. If direct input were trusted, users could abuse the application for many malicious purposes such as compromising the host or retrieving protected information. For more information, see the following CERT advisories and referenced articles:

  1. Advisory CA-1997-25: Sanitizing User-Supplied Data in CGI Scripts
  2. How To Remove Meta-characters From User-Supplied Data In CGI Scripts (CERT Coordination Center article)
  3. Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests
  4. Scriptlet Security (Microsoft Developers Network article)

Never Trust Client Data

  • Validate client IP addresses.   Never trust the client machine to tell you its IP address or DNS name.  If you’re restricting a function to certain IP numbers, check the actual remote IP address of the connection.  If you’re doing restrictions by DNS name, translate that numeric IP address to a name, then translate that name back to a number.  Only accept the name if the number you get back matches the number you started with.
  • Use server-side validation of all commands.
  • Environment variables, like HTTP_REFERER and REMOTE_USER should never be used to implement restrictions, as they are easily spoofed.
  • Consider replay attacks as well as spoofing.  The attacker does not have to guess what a valid session ID would look like if s/he can just use somebody else’s.

Special Characters Certain characters are interpreted by the operating system (both Unix and Windows) to perform functions, such as sending output of one program to another. The preferred approach is to specify exactly what data is allowed.  Also, do not rely on client-side validation such as JavaScript to validate user input.  Always validate on the server. Finally, if your application development environment supports it, do taint checks, which cause an application to fail if user input is used when executing system commands. In Perl, for example, taint checks are enabled with the -T switch.Malicious HTML HTML tags can be abused to change the display of an application or even execute code on the client machine. If HTML tags are used by users to format text input, always be sure to explicitly define which tags are allowed. For example, tags other than <P>, <B>, <I>, and <FONT> could be stripped.

Buffer Overflows and Memory Management

Format bugs Programmers should never allow the user to specify his own format string:
read(sockfd,buf,sizeof(buf));
syslog(LOG_ERR, buf); /* BAD, allows user to specify format string */

This allows the user to send in arguments like the following:
char *garbage = “%s%s%s%s%s%s%s%s <a lot of garbage>”
write(sockfd, garbage, sizeof(garbage))
Which can cause the reading app to move up and down the stack and possibly overwrite areas of memory, similar to the way buffer overflows work.

Be sure all such routines that take a format string have a developer-supplied format string:
read(sockfd, buf, sizeof(buf));
syslog(LOG_ERR, “%s”, buf); /* GOOD, developer-supplied format string */

Form implementation: POST vs. GET When using forms, prefer POST to GET. The GET method transfers all information to the application in the URL.

Example:
http://www.somedomain.ufl.edu/cgi-bin/application.cgi?username=johndoe&password=noel

This information is much more visible to casual observers and is logged in many places. POST, on the other hand, is hidden from the browser screen, is not logged and does not have some of the size and content restrictions of GET.

Data Injection and Cross-site Scripting Two examples of application abuse when proper data validation does not occur are data injection and cross-site scripting.  Data Injection allows the user to specify extra information along with legitimate input, and cross-site scripting is a relatively new form of attack in which data is embedded by a user which is presented to other users and executed in some manner to cause other clients to behave in an undesirable way.  For example, a user may post an image in a comment to a forum, which other users browsers will automatically visit, potentially giving away cookie or other session information.  For more information on cross-site scripting, see the CERT documents Malicious HTML Tags Embedded in Client Web Requests  and Understanding Malicious Content Mitigation for Web Developer.

Web Security Important to note:  The sample CGI applications that come installed on many Web servers often represent a serious security risk. For more information, see the UF Network and Host Security Standard and Procedures. Securing Web Services With Secure Socket Layer (SSL)

SSL is a commonly used Web protocol that uses strong encryption to communicate securely, it also allows the browser to authenticate the server and detect whether the data has been altered or tampered with in transit.  Fully compatible with the Web’s most popular browsers, SSL is used by many major e-commerce Web sites. When users connect to a secure Web server using SSL, such as https://www.someunit.ufl.edu/ (note that the “s” indicates a secure server), that server authenticates itself to the Web browser by presenting a digital certificate. Digital certificates are issued to Web sites by a Certifying Authority (CA) , once the CA is satisfied 1) as to the identity of the requester and 2) that the requester actually owns, or has the right to use, the domain name for which the certificate will be issued. A valid certificate gives customers confidence that they are sending personal information securely and that it is going to the right place.

To build secure applications, particularly web applications, it is imperative that a series of requests from a particular client be associated with each other and that the server be aware when the client is no longer active. This set of precautions is known as session management. Without session management, an unauthorized user could gain access to personal data from UF systems by assuming an idle session.

Session management is especially important for web applications, since they do not establish a persistent connection between client and server, but send each page as a separate network connection. However, even applications which use persistent network connections can benefit from the guidelines below.

Many different techniques may be employed. Your choices will be determined by your platform, server software, application software, programming language, and your desired level of security. Listed below are some ways that UF application developers can use session management techniques to protect data served via UF applications

How to Set Up a Secure Web Site at UFDeploying a secure Web service at UF involves a few administrative steps.  First, identify which entity is hosting your Web site. If your site is hosted by Computing and Networking Services ( formerly NERDC) on their NERSP machine, then they can handle the whole process for you. Contact the Open Systems Group (open-systems-l@lists.ufl.edu or (352) 392-2061) to request secure Web services on the NERSP. If you are hosting your Web site locally on your own machine, then you will have to follow these steps:

  1. Have your system administrator generate a public/private key pair for the Web server you would like to secure.
  2. Submit your digital certificate to be signed by a well recognized certifying authority (CA), i.e.: Thawte,Verisign, etc.
  3. Install the digital certificate on your Web server and create a domain name entry for the secure (https) service.
  4. Make sure the secured resources can’t be accessed by the insecure [http] methods.
  5. Keep your digital certificate up to date; they are time limited.

Questions about setting up secure Web services should be directed to the NERDC Open Systems Group at open-systems-l@lists.ufl.edu or (352) 392-2061. Databases and Other Data Storage If external files are used in your application, further checks must be done to ensure that malicious users are not exploiting the application to retrieve sensitive information. Use the following guidelines when reading from or writing to external files:

  1. Authenticate connections from the web server.
  2. Consider encrypted database connections if the database server is not on the same machine as the web server or on the same local network segment.
  3. Do not put passwords in scripts.  If the script needs a password, for instance, to connect to a database, it should read that password from a protected configuration file.
  4. Allow backend database access only from the web server if possible.
  5. Files that are properly protected from unauthorized web access are not necessarily properly protected from other methods of access.
  6. Use a data directory. Data files should not be placed in the cgi-bin directory or in any directory that can be accessed from a Web browser.
  7. Do not use raw path and filenames. Never accept user input as the path information for a file. Instead, use some type of identifier for the form which points to an actual file.
  8. Use absolute paths. Do not assume that an application is being called from a certain directory. Use a fully qualified path to the files your application accesses.
  9. Specify the mode when opening a file. Configuration files should be specified as read-only, data files should be specified as write-only, and log files should be specified as append-only.
  10. Avoid temp files
  11. Maintain current patch levels

Using UF Data Resources User supplied data is frequently misspelled, incomplete or missing.  Applications that rely on personal data supplied by the user are vulnerable to data corruption.  Applications should therefore limit the amount of personal data input from users.  Instead, it is highly recommended that campus developers require user authentication from official UF systems. Personal data about authenticated users can then be acquired from official university directory resources as described below.

Overview of UF directory service methods The DB2 database is the authoritative source for University of Florida directory information.  It is maintained by Information Systems and resides on a mainframe computer at the Northeast Regional Data Center (NERDC). As the official UF directory, this database contains student and employee demographic data. Access to the official directory is restricted to authorized applications.

The LDAP directory is essentially a copy of the official database and is maintained by NERDC. However, the data model is slightly different and so are the access methods and security restrictions. Most data is public, in fact the “phonebook” function accessible through the main UF Web site is powered by this LDAP data. However, LDAP does contain some secure data, which are available only to authorized users.  Also, some users will not be accessible to unregistered applications from LDAP if their privacy flag is enabled.

These directories can be accessed from a variety of programming languages and methods such PERL, Java, etc.  Secured access can be obtained by justifying your needs to the appropriate controlling entities.  (contact info needed)

Use Enterprise Data Obtain preferred email addresses, mailing addresses, UFIDs, or other information about UF users from the UF LDAP or DB2 directories.  Since all members of the UF community are required to have a GatorLink account, login the user with GatorLink via OIT’s Shibboleth authentication server.   The GatorLink ID can be extracted from the authentication server response when you validate the user’s browsers cookie used to keep track of logins, then used to query the directory.

References

Updated October 24, 2003