Application Security
Advances in web technologies coupled with a changing business environment, mean that web applications are becoming more prevalent in corporate, public and Government services today. Although web applications can provide convenience and efficiency, there are also a number of new security threats, which could potentially pose significant risks to an organisations information technology infrastructure if not handled properly. The rapid growth in web application deployment has created more complex, distributed IT infrastructures that are harder to secure. For more than a decade, organisations have been dependent upon security measures at the perimeter of the network, such as firewalls, in order to protect IT infrastructures.

Application Security

However, now that more and more attacks are targeting security flaws in the design of web applications, such as injection flaws, traditional network security protection may not be sufficient to safeguard applications from such threats. These threats originate from non ­trusted client access points, session­ less protocols, the general
complexity of web technologies, and network ­layer insecurity. With web applications, client software usually cannot always be controlled by the application owner. Therefore, input from a client running the software cannot be completely trusted and processed directly. An attacker can forge an identity to look like a legitimate client, duplicate a user ‟ s identity, or create fraudulent messages and cookies. Hypertext Transport Protocol messages can easily be modified, spoofed and sniffed.

Administrative controls

The following are recommended administrative controls that may help in strengthening the security of web applications and protecting data handled by such applications.
1.Put in place key guidelines to provide direction on the development and maintenance of websites and/or online applications.
2.Put in place key guidelines on coding and development practices for web applications. Software development teams should follow a set of secure web application coding practices, designed to combat common web application security vulnerabilities.
3.Collect and manage sensitive information and user data in compliance with policy and regulations.
4.Prepare a security and quality assurance plan, and adopt quality assurance methods such as code review, penetration testing, user acceptance tests, and so on;
5.Perform a complete IT security audit before the final production launch of a web application, and after any major changes or upgrades to the system.
Common Vulnerabilities in Web Applications.These are the common vulnerabilities in web applications

1.Cross Site Scripting (XSS)

The potential threat of XSS is allowing the execution of scripts in the victim’s browser that could hijack user sessions, deface websites, and possibly introduce worms, etc. This flaw is caused by the improper validation of user­supplied data when an application takes that data and sends it to a web browser without first validating or encrypting the content.

2.Injection Flaws

The potential threat from this flaw is that an attacker could trick the application into executing unintended commands or into changing system data. Injection flaws, particularly SQL injection, are common inweb applications. Injection occurs when user­supplied data is sent to an interpreter apart of a command or query.

3.Malicious File Execution

The potential threat to code vulnerable to remote file inclusion (RFI) is that it could allow attackers the opportunity to include hostile code and data, resulting in devastating attacks, such as a total compromise of the server. Malicious file execution attacks can affect PHP, XML and any framework that accepts filenames or files from users.

4.Insecure Direct Object Reference

The potential threat here is that attackers could manipulate those references to access other objects without authorization. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.

5.Cross Site Request Forgery (CSRF)

The potential threat from this flaw is that it might force a logged­on victim’s browser to send a pre­authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

6.Information Leakage and Improper Error Handling

The potential threat from this flaw is that attackers can use this weakness to steal sensitive data, or conduct more serious attacks. Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems.

7.Broken Authentication and Session Management

The potential threat here is that attackers might compromise passwords, keys, or authentication tokens in order to assume the identity of other users. This flaw Web Application Security is caused when account credentials and session tokens are not properly protected.

8.Insecure Cryptographic Storage

This potential threat comes when attackers use poorly protected data to conduct identity theft and other crimes, such as credit card fraud. This flaw is due to web applications not making proper user of cryptographic functions to protect data and credentials.

9.Insecure Communications

This flaw comes from the possible leakage of sensitive information over the network
communication infrastructure. This is caused by a failure to encrypt network traffic when it’s necessary to protect sensitive communications.
10.Failure to Restrict URL Access This flaw gives attackers the opportunity to access and perform unauthorized operations by accessing those URLs directly. This flaw is caused by applications that only protect sensitive functionality when preventing the display of links or URLs to unauthorized users. Application developers should be aware of these common security flaws and develop programming standards
that avoid such problems in the coding phase. Define secure Coding standards
The OGCIO(Office of the Government Chief Information Officer) has also included a set of common secure coding practices in their IT Security Guidelines:

1.Validate all input parameters to prevent attacks such as SQL injection and cross­site scripting attacks:
Programmers should develop a centralized module to perform input parameter validation, and check each input parameter against a strict format that specifies exactly which types of input will be allowed. Special characters such as “~!#$%^&*[]<> ‟ \r\n” coming from the input form should be filtered, or replaced with an escape sequence. Client­side scripts should not be relied on to perform the necessary validation checks. The application should only accept data containing a strictly limited and expected set of characters. If a number is expected, only digits should be accepted.

If a word, only letters should be allowed. Input data should also be validated for the proper format. If an email address is expected, only letters, numbers, the “at” (@) symbol, dashes, and dots in the proper arrangement should be accepted. Enforcing minimum and maximum length restrictions on all incoming data should also be included. This technique should be used for account numbers, session credentials, user names, and so on. All these techniques restrict the number of potential entry points for incoming attacks.

2.Sanitised application response

A centralized module should be developed to perform any sanitisation. All output, return codes and error codes from calls (e.g. calls to the backend database) should be checked to ensure that the processing expected actually occurred. For example, unnecessary internal system information such as internal IP addresses, internal host names, internal directory structures, verbose error messages generated by internal server errors during a response should not be exposed on the client side. Most application/web servers allow the generation of a custom error page should an internal server error occur.

3.HTTP trust issues

Programmers should not trust or rely on HTTP REFERER headers, form fields or cookies to make security decisions, as this type of data can be spoofed. Unless strong cryptographic techniques are used to verify the integrity of HTTP headers, do not trust these parameters coming in from a client browser. In addition, do not assume hidden parameters cannot be changed by the user, as hidden parameters can be easily manipulated by attackers.

4.Keep sensitive session values on the server to prevent client­side modification

Do not put sensitive information in any client browser cookies. If sensitive values have to be stored in a client browser, strong cryptographic techniques should be used to protect the confidentiality and integrity of the data.

5.Encrypt pages containing sensitive information and prevent caching

Pages containing sensitive information should be encrypted with proper algorithms and keys such as SSL and TLS during transmission. Use signed Java applets or ActiveX to acquire and display sensitive information, and set the appropriate HTTP header attributes to prevent caching, by browser or proxy, of an individual page should that page contain sensitive information.

6.Session management

A session ID should be long, complicated, contain random numbers that are unpredictable, and it should be changed frequently during a session to reduce the duration that a session ID remains valid. In addition, a session ID should not be stored in a URL, persistent cookies, hidden HTML fields or HTTP headers. Programmers can consider storing session IDs in a client browsers session cookies. By employing SSL or TLS, session IDs can be protected from sniffing by attackers. A logout function for the application, and an idle session timeout should also be implemented. When logging off a user or timing­out an idle session, not only should the client­ side cookie should be cleared (if possible), but also the server side session state for that browser plus connections to backend servers should be cleaned up.

7.Access restriction

Ensure that the end­user account only has specific privileges to access those functions that they are authorized to access, restricting access to the backend database, or to run SQL commands, and OS commands. When an application makes system calls to access certain programs, do not make calls to actual file names and directory paths. If attackers have access to the source code,
they may uncover system­level information. Use mapping provided by the web server as a filtering layer .

8.Build a centralized module for application auditing and reporting.

9.Use the most appropriate type of authentication method for the job, to identify and authenticate incoming user requests.

Security Measures on web applications

Ongoing security measures can include the following:
1.Application Log ReviewTo detect any anomaly in a web application, a log review is indispensable. Many web servers support detailed logs that capture all web requests made to the web application. By regularly reviewing the web access log and studying web requests made to the application, it is possible to gain significant insight into the safety of the web application. If abnormal URLs are uncovered, it is very likely that some kind of web attack have taken place.In addition, application owners can
also request the implementation of application audit trails for the web application. Exception reports to undefined requests, or abnormal transactions should be generated and reviewed regularly.

2.Version Control and a Separate Environment for Development

The integrity of an application should be maintained with appropriate security controls such as a version control mechanism and the separation of environments for development, system testing, acceptance testing, and live operation. The production and development environments should be kept synchronised. Application development staff should not be permitted to access production information unless absolutely necessary.

3.Web Application Firewalls

Standard firewalls can help restrict or permit network access to network ports authorized by the organisation. Although application proxy firewalls exist, they cannot understand the specific content of all web applications being run by the organisation. According to the Web Application Security Consortium, a web application firewall (WAF) is “an intermediary device, sitting between a web­client and a web server, analysing OSI Layer­7 messages for violations in the programmed security policy”. Usually, web application firewalls are installed in front of a web
server. Like standard firewalls, these can be software or hardware based, but always with the purpose of protecting the web server from attack.
There are two protection approaches:
1.Signature based: The WAF identifies attacks by checking web request against an
“attack signature” file.
2.Abnormal behavior based: The WAF identifies attacks by detecting abnormal
traffic patterns.

© 2017 – 2018, Techrunnr. All rights reserved.

Questions Answered
Articles Written
Overall Points
Categories: Security

Prabhin Prabharkaran

He is Technical professional. He is a person who loves to share tricks and tips on the Internet. He Posts what he does!!

Leave a Reply

Please wait...

Subscribe to our newsletter

Want to be notified when our article is published? Enter your email address and name below to be the first to know.