Question

It takes a lot of work to create really great applications and even more to maintain the evolution of those applications over time. In the past 20 years, the Internet has progressed exponentially. Take, for example, the original Facebook page, which was called www.aboutface.com in 1999. If you use the Internet archive site called the Wayback Machine at www.archive.org , you can see what Facebook looked like two decades ago (see Figure 11.1 ). What I love about the Wayback Machine is that if you want, you can right‐click the website archived and view the page source.

Figure 11.1 : The original Facebook.com in 2000 called AboutFace.com

The progression of the Web has led to a need for the evolution of web application testing. Back in the day, a web page was a static page, and the flow of information was from server to browser. Most sites did not require any type of authentication because it just wasn't needed. Any issue you had was as a result of vulnerabilities in a web server. Now what you see are web applications that are dynamic and customized for each user, and the problem is private data being exposed to the public, not just web server files.

Every developer I know says that the foundation of a strong application is the framework and architecture it is built on. Web application architecture is the interaction between applications, middleware, and the databases the application relies on. It is critical that when a user hits the Submit button through any browser that the information is processed correctly. Middleware is the software that provides services to applications besides those offered by the operating system. Any software between the kernel and the application can be middleware. Some describe middleware as “software glue.”

You type in a URL, and the browser finds the Internet‐facing server that hosts that website and asks for that particular page within that site. The server responds by sending the appropriate files to the browser to execute. Now you get to interact with the website. The most important thing here is the code. The code gets parsed by the browser, which may or may not have specific instructions to tell the browser what to do. The web application framework and architecture have all the components and routines and interchanges needed for the application.

Ultimately, the design of web applications is for usability. You want an application to accomplish goals efficiently. This is critical for many organizations since the majority of global business and our lives are on the Internet. Every application and device today is built with the idea of web‐based interaction. You have Amazon for shopping, Instagram to keep up with friends, JPMorgan Chase for banking, and all the email you send using Google or Yahoo!. Even when you have the assurance that these web applications are protected and the lock icon appears in the browser and the application states that they are secure because they are using SSL or they are compliant with PCI‐DSS, the websites have fallen to vulnerabilities such as SQL injection, broken access controls, cross‐site scripting, or request forgery. Even if SSL is being used, which encrypts links between a web server and a browser, there can still be vulnerabilities in the web application.

To make it even more complicated as a security professional, you are faced with all the different frameworks and languages that web applications are built with. The most popular ones include the following:

• Angular: Framework built by Google and uses JavaScript
• Ruby on Rails: Framework for the object‐oriented Ruby
• YII: Open‐source framework using PHP5
• MeteorJS: Developed in Node.js , primarily for mobile devices
• Django: Written in Python for complex websites

Choosing the right framework for development in this dynamic process is critical. Some of these languages specifically answer the need for speed, scalability, or complexity. No matter the framework or language, security should always be factored into the SDLC, no matter the size of the project, and even more so in the applications that store personal information of the users who utilize that software. As you see in Figure 11.2 , the SDLC begins with analyzing the requirements of a project. Questions asked at this stage should not be limited to the who, what, when, and where of the application, but should also include a risk assessment of the impact of a compromise of this theoretical application you're designing.

Figure 11.2 : The software development lifecycle with security functions embedded at every stage of the process

Looking back over the past year, some of the biggest breaches were accomplished by either weak security practices like a misconfigured database, social engineering, or vulnerabilities in web applications. The rise of the Internet of Things has led to many complicated problems—especially when some of the life‐saving devices such as pacemakers or insulin pumps are shown to be vulnerable through poor encryption—and leaves software susceptible to malware infection. Even the cars we drive have to be evaluated on the size of their attack surface and network architecture. If your automobile offers features like Bluetooth, Wi‐Fi, cellular network connections, keyless entry, or radio‐readable tire pressure, monitoring systems can offer a security vulnerability to gain an initial foothold into the car's network.

There are many reasons for problems in securing web applications. One of the major problems is the lack of developers' security awareness, as mentioned at the beginning of the chapter. Add to that the customization of web applications by in‐house staff, the threat actors developing new web attack techniques, and time constraints where you have to get a web application to production as soon as humanly possible. This all leads to serious threats to both the company hosting the web application and the users who share their credit card information on them.