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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Astronomy for KDE
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- OpenSwitch Finds a New Home
- Git 2.9 Released
- What's Our Next Fight?
- Snappy Moves to New Platforms
- The Giant Zero, Part 0.x
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide