Serverless is a highly trending term in the world of software architecture right now and one can judge this from the many references of the term in journals, products, and open s...
By: Kallappa Patil | November 20, 2017
Research estimates that 75% of attacks against Web servers are entering through applications and not at the network level. And when a company makes even minor changes on its websites and applications, new vulnerabilities can arise. Application vulnerabilities are often neglected, but they are as important to deal with as network issues. If every company eliminated [the OWASP Top 10 Critical Web Application Security Vulnerabilities], their work wouldn’t be done, but they, and the Internet, would be significantly safer.
By design, the network must route legitimate traffic to the critical resources housing business logic in the form of applications. Network security protects the integrity and reliability of the traffic to critical resources, but application logic must determine what input or transactions are legitimate. Manipulation and corruption of application logic is an attacker’s approach to compromising business data.
An application which stores and processes customer data generated from legitimate businesses, is an attractive target for hacking and for spies.
Both end user and corporate firms depend on the effectiveness of the application’s security controls. Inappropriate disclosure of customers’ data can have consequences, ranging from violation of laws, financial loss and loss of customer trust. Thus, the application should be carefully controlled and thoroughly secured from malicious attacks.
Although risks are often classified as intentional or accidental or whether the attack is internal or external, an internal attacker could have additional knowledge about the application logic and database structure that could make an attack more damaging. There are some useful websites like OWASP www.owasp.org. that offer a list of the most critical web application vulnerabilities.
Currently, security auditing of web applications is still in its infancy. However, some tools exist that assist in audit. In many cases, the most effective approach is to review the application development policies, design requirements, and application code, and there are two reasons for this: to catch errors at the earliest possible stage of the development process and to prevent or uncover insider attacks by developers.
Let’s learn about the best industry standard Web application security guidelines for developers.
Improper Error Handling Checklist
Improper handling of errors can introduce a variety of security problems for a website. The most common problem is when detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the user (hacker). These messages reveal implementation details that should never be revealed. Such details can provide hackers important clues on potential flaws in the site and such messages are also disturbing to normal users.
Buffer Overflows Checklist
Attackers use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code – thus effectively taking over the machine. Buffer overflows are not easy to discover and even when one is discovered, it is generally extremely difficult to exploit. Nevertheless, attackers have managed to identify buffer overflows in a staggering array of products and components.
Unvalidated Input Checklist
Web applications use input from HTTP requests (and occasionally files) to determine how to respond. Attackers can tamper with any part of an HTTP request, including the URL, query string, headers, cookies, form fields, and hidden fields, to try to bypass the site’s security mechanisms.
Before the application responds to the HTTP request, the input or file must be broken down into its simplest form and validated. Client-side validation has no security value because attackers can bypass that processing and send whatever they want. If client side validation is used, it should mirror the server-side validation logic. The simplest way to find uses of unvalidated input (tainted parameters) is to have a detailed code review, searching for all the calls where information is extracted from an HTTP request.
Denial of Service Checklist
Web applications are particularly susceptible to denial of service (DoS) attacks. A web application can’t easily tell the difference between an attack and ordinary traffic. There are many factors that contribute to this difficulty, but one of the most important is that, for several reasons, IP addresses are not useful as an identification credential. Because there is no reliable way to tell where an HTTP request is from, it is very difficult to filter out malicious traffic. For distributed attacks, how would an application tell the difference between a true attack and multiple users all hitting reload at the same time (which might happen if there is a temporary problem with the site)? To reduce the risk, developers can set a limit on the number of sessions per user.
Broken Access Control Checklist
Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. Access control, or authorization, needs to be implemented in a careful, well-designed way. If access control logic is spread throughout the application code, it can be very difficult to validate, test, and maintain.
One particular type of access control problem is associated with remote administration interfaces. These interfaces could permit administrators to administer site users, data, and content from a remote location. These interfaces prove to be attractive targets for attackers.
Broken Authentication and Session Management Checklist
Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermining of authorization and accountability controls, and privacy violations. Configuring Secure Sockets Layer (SSL), SSH may help minimize such risks.
Cross-site Scripting (XSS) Flaws Checklist
Cross-site scripting (XSS) vulnerabilities occur when an attacker uses a web application to send malicious code, generally in the form of a script, to a different end user. These flaws are quite widespread and occur anywhere a web application uses input from a user in the output it generates, without validating it.
An attacker can use cross-site scripting to send malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source. The malicious script can access any cookies, session tokens, or other sensitive information retained by your browser that is used with a particular site. These scripts can even rewrite the content of the HTML page.
Injection Flaws Checklist
Injection flaws allow attackers to relay malicious code through a web application to another system. These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Any time a web application uses an interpreter of any type, there is a danger of an injection attack.
If a web application uses operating system functions or external programs to perform its functions, and passes http input to the external function, the http input must be carefully scrubbed. Otherwise, the application may be open to injection flaws. The consequences could range from small to complete system compromise or destruction. Since the use of external functions is common, the likelihood of the web application having an injection flaw should be considered very high.
Insecure Storage Checklist
Most web applications have a need to store sensitive information, either in a database or on a file system somewhere. The information might be passwords, credit card numbers, account records, or proprietary information. Frequently, encryption techniques are used to protect this sensitive information. While encryption has become relatively easy to implement and use, developers still frequently make mistakes while integrating it into a web application. Developers may overestimate the protection gained by using encryption and not be as careful in securing other aspects of the site.
So, we see that effective web application security is all about being aware of the best practices and adhering to the industry standard Web application security guidelines during development. The key is to ensure your application has minimum possible vulnerabilities. Violation of web application security can have dire consequences and so it’s a priority for the developers to focus on the application security controls.
Learn more about our Services and Solutions in the Information and Data Security space.
To schedule a meeting or for more information, please write to us at firstname.lastname@example.org