Assessing the Security of Your Web Applications
Sometimes forms are filled out in sequence. This may be necessary because the information provided in one form is used to take the user to the next form in the web application. Additionally, the entire web application may be divided into multiple forms for ease of use.
Malicious users may be able to bypass the intermediate forms by typing out the entire form name in the browser URL field instead of using the navigation controls provided by the web site pages. This may result in unexpected application behavior, accessing a defunct application, incomplete database records or buffer overflow.
Security measures you can take are:
Ensure the user progresses to the next form only after all the required information requested in the preceding forms is provided. Furthermore, ensure the user visited all preceding forms.
Perform referrer checks on the server side. This will ensure a given form was reached from the page that contains the hyperlink providing access to the form.
Many times, form fields are used to send input provided by users to the back end web site for further processing. For example, a user may input their user ID or full name to list information pertaining to their user account. Once the web server receives this information, it will issue a query to a relational database. The results of the query are displayed to the user.
A malicious user may input field entries in such a way that the returned result provides additional information about other users as well. In addition, the embedded queries may run other SQL commands, such as pipe commands, which may result in disclosure of confidential information.
Security measures you can take are:
The web application must carefully examine the input fields used to create the database queries for illegal characters, for example an asterisk (*).
Validate and ensure that input fields contain only the relevant user-related information.
Ensure proper permissions exist on the database objects accessed by the web application.
Many site administrators feel secure simply because the site is using SSL for all its sessions. SSL provides for data transmission security between the web client and the web server. Once an SSL session is established, all information exchanged between the web server and the web client is encrypted. The session timeout specifies the “no activity” duration beyond which the user will have to re-authenticate himself to the web site. The session timeout is usually based on the type of application. Serious financial institutions may specify a very short session timeout period. Regular applications, such as web-based e-mail, may use longer timeout periods.
A malicious user may be able to hijack another user's session if session timeouts are too long. The implications of this are widespread, ranging from embarrassment to loss of confidentiality and integrity of user information. This is a major issue in kiosk, cyber café, laboratory and shared workstation environments.
Your security measure is to evaluate carefully the session timeouts for your application. If you are using multiple application servers, then ensure the session timeouts for the multiple applications are consistent with the timeouts determined for the entire web site.
Most servers are configured with automatic directory listing. This means any directory that does not contain any of the default files (for example, index.htm or default.htm) served by the server will display the contents of the directory. This is dangerous for directories where CGI program sources or executables reside. Further, these directories may contain other files (for example, files with the ~ prefix or the .bak suffix) that may provide more information on the web-site application.
Malicious users may be able to browse the directories and download key files. Files that contain source code may be examined to identify trap doors to gain access into the web server or applications.
The security measures you can take are:
Configure the web server to specify all default files that may be used and to disable directory browsing.
Establish proper procedures when adding the web-application files.
Ensure that unnecessary files are periodically removed.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development