Application Security

Posted in Technopedia, Application Security

Application security is the use of software, hardware, and procedural methods to protect applications from external threats. Security measures built into applications and a sound application security routine minimize the likelihood that hackers will be able to manipulate applications and access, steal, modify, or delete sensitive data. Once an afterthought in software design, security is becoming an increasingly important concern during development as applications become more frequently accessible over networks and are, as a result, vulnerable to a wide variety of threats.

Actions taken to ensure application security are sometimes called countermeasures. The most basic software countermeasure is an application firewall that limits the execution of files or the handling of data by specific installed programs. The most common hardware countermeasure is a router that can prevent the IP address of an individual computer from being directly visible on the Internet. Other countermeasures include conventional firewalls, encryption/decryption programs, anti-virus programs, spyware detection/removal programs, and biometric authentication systems.

Application SecurityApplication security can be enhanced by rigorously defining enterprise assets, identifying what each application does (or will do) with respect to these assets, creating a security profile for each application, identifying and prioritizing potential threats, and documenting adverse events and the actions taken in each case. This process is known as threat modeling. In this context, a threat is any potential or actual adverse event that can compromise the assets of an enterprise, including both malicious events, such as a denial-of-service (DOS) attack, and unplanned events, such as the failure of a storage device.
How hackers execute attacks against custom applications

Most initial attacks against your systems are likely to focus upon the systems infrastructure and commercial applications, as that is where most of the exploit material and methodologies are likely to work. Depending upon the skills or resources, if your systems are well secured and up to date with the latest bug-fixes or patches, the attacker may either resort to social engineering (Why try to crack a password when you can just call the helpdesk and have it reset?) or focus upon the manipulation of the vulnerabilities inherent in the application, or sub-components. Although custom applications can be vulnerable to a number of attack methodologies. Four attack categories are most prevalent:
  • Buffer overflow attacks - Buffer overflow attacks are aimed at application components that take data as an input and pass it to memory buffers for later use and manipulation. Failure to adequately check the size of data before passing it into too small a buffer is commonplace. Attackers may be able to include their own embedded commands within the oversized data package and thus have their commands replace existing application code and execute on the system. If successfully executed, these commands will enable attackers to acquire privileges that exceed authorised permissions up to, and including, those of the system administrator - with corresponding control of the host system. In some circumstances, application components subject to a buffer overflow may suspend or crash, thus denying users further access to the service. In other cases such an attack may bring down the host server and deny access to any services provided by the system.
  • Race conditions - Under certain circumstances, when an application requires access to specific files, variables or data, its programmers may not have correctly implemented multiple simultaneous accesses and installed the appropriate checks. This can often lead to an attacker enjoying unintended access to files or data through trusted and untrusted server application components.
  • Exploitation of application component privileges - Server based application components run with specific group or user permissions, not necessarily with that of the user running them (such as an anonymous Web user). These application components, if they suffer additionally from buffer overflows or race conditions, can be used to increase access and escalate the potential damage to the system.
  • Client-side manipulation - To speed up connectivity and reduce performance loads at the server end, client-side validation of input and manipulation of data is often required. It is often a relatively trivial exercise for attackers to bypass this checking and supply incorrect data or data formats to the server in an attempt to initiate any of the other three common attack formats or to reveal both confidential information and server application functionality. This method is also a popular means of conducting fraudulent transactions on commerce-enabled sites by changing the values of available products.

General advice on securing custom applications

The Author is often asked for advice on best practices for securing applications to minimise the developer's time for correcting potential flaws that may be discovered during a security assessment. Several steps should be undertaken, or at least borne in mind, in order to maximise security and data integrity during the process of building a new application:
  1. Assume that someone out there will intentionally try to break your application and may have access to greater resources than you expended in developing it.
  2. Assume that you will receive erroneous data from authorised, authenticated users, and develop a way to deal with it.
  3. If you choose to use client-side input validation, ensure that the input is also validated at the server end.
  4. Avoid complex code and use minimal coding structures for handling performance related issues.
  5. Be careful with application component privileges. Always apply the minimum possible permissions needed to carry out any particular task.
  6. Utilise methods of load limiting to prevent overloading application components or servers.
  7. Check every return code from system components and functions to prevent race conditions or malicious input.
  8. Never allow passwords or user specific details to be passed in plain-text to the client browser or between application components.
  9. Ensure that confidential system information is not encoded into documents that could potentially be accessed by a remote client, either directly or through escalated application component permissions and calls.
  10. Commonly available libraries or sample code may not necessarily be secure. Review carefully any third-party code.
  11. Always use full pathnames in system and application procedure calls to prevent redirection and unexpected use.
  12. Take extreme care with file permissions and access rights.
  13. Remove all unnecessary material from the hosting servers and only install services that are required for the application/system to function.
  14. Remove all comments and unnecessary information from client-side code.
  15. Distribute application functions between servers when possible to limit data access from a compromised host.
  16. Use reasonable system timeouts for network reads and writes to help prevent race conditions being reached and denial of service attacks.
  17. Ensure you are capable of logging and tracking all inbound requests for post attack analysis.
  18. Where possible, only use shared resources you have direct control over. If this is not possible, ensure appropriate checks for data integrity are made.
  19. Test the application thoroughly!
  20. Get a third party to perform an independent assessment both of the application's security and the system's host servers before going live.

References:
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1158766,00.html
http://www.technicalinfo.net/papers/ApplicationSecurityAssessments.html

Share This

Comments (0)

Leave a comment

Please login to leave a comment. Optional login below.