The cloud application runs on servers and we spoke about ensuring that these servers are fully patched. However, what about the applications themselves? They are exposed to vulnerabilities that are introduced due to bad coding practices of the programmers. SQL injection, cross site scripting, and exception management are some of the application security bugs the creep into the code.

Let us look at each one of them in detail and then we will talk about what we can do to detect them during the testing phase. The OWASP organization lists the top application vulnerabilities as follows: SQL injection, broken authentication, cross site scripting, insecure direct object reference, security misconfiguration, sensitive data exposure, missing function level access control, cross site request forgery, component with known vulnerabilities, un-validated redirects and forwards. SQL injection happens when untrusted data is sent to an interpretor as part of a command or query. The attacker's hostile data can trick the interpretor into executing unintended commands or accessing data without proper authorization. Broken session management happens when application functions related to authentication and session management are often not implemented correctly. This allows attackers to compromise passwords, session tokens, or to exploit other implementation flaws. Cross site scripting flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. Cross site scripting allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface websites, or redirect the user to malicious sites. Insecure direct object reference happens when a direct object reference occurs when a developer exposes a reference to an internal implementation object such as a file, directory, or database key without an access control check or other protection in place. Attackers can manipulate these references to access and authorize data.

Security misconfiguration requires good security, having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained as defaults are often insecure. Additionally, software should be kept up to date. Sensitive data exposure happens when web applications do not properly protect sensitive data such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves excellent protection such as encryption at rest or in transit as well as special precautions when exchanged with the browser. Missing function level access control, most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed.

If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization. Cross site request forgery happens when an attacker forces a logged-on victim's browser to send a forged HTTP request, including the victim's session cookie and any other automatically included authentication information to a vulnerable web application. This allows the attacker to force the victim's browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Components such as libraries, frameworks, and other software modules almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts. Web applications frequently redirect and forward users to pages and websites and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages. These bugs are the result of bad coding practices by programmers. OWASP website has a very detailed analysis of how these bugs can be detected and corrected.

That analysis is outside the scope of this course and is a week-long course all by itself. What is critical is that the Software Development Life Cycle or SDLC has to factor in testing the software for these defects and this has to be worked into the rigor of software development. A lot of development groups usually push back on this testing because it adds significant overheads to development timelines. Also, many apps and SaaS websites have close to three software releases a day. To factor in security testing into such tight timelines is extremely difficult. What we need to do in such situations is to work with the development teams and work out the best alternatives so that the code that runs on the cloud is bug-free.

A possible solution is application testing can be done once a week or once every major release. This, once again, is dependent on the risk appetite of the company. The higher the risk appetite, more frequent the testing and longer the development timelines.