Every newly deployed web application creates a new security hole and potential access of your organization’s data. Hackers gain access to data by sneaking through ports that are supposedly hidden behind firewalls. There is no way to guarantee that your web application is 100 percent secure. If it has never been attacked by hackers, most likely it’s too small and is of no interest to them.
This chapter provides a brief overview of major security vulnerabilities of which web application developers need to be aware. We also cover delegated authorization with OAuth, and possible authentication and authorization scenarios for our Save The Child application.
There are plenty of books and online articles that cover security, and enterprises usually have dedicated teams handling security for the entire organization. Dealing with security threats is their bread and butter, and this chapter won’t have revelations for security professionals. But a typical enterprise application developer just knows that each person in the organization has an account in some kind of a naming server that stores IDs, passwords, and roles, which takes care of authentication and authorization flows. Application developers should find useful information in this chapter.
If an enterprise developer needs access to an internal application, opening the issue with the technical support team grants the required access privileges. But software developers should have at least a broad understanding of what makes a web application more or less secure, and which threats web applications face—this is what this chapter is about. To implement any of the security mechanisms mentioned in this chapter, you’ll need to do additional research.
|
Tip
|
A good starting point for establishing security processes for your enterprise project is Microsoft’s Security Development Lifecycle website. It contains documents describing the software development process that helps developers build more secure software and address security compliance requirements while reducing development costs. |
Imagine a popular nightclub with a tall fence and two entry doors. People are waiting in lines to get in. Door number 80 is not guarded in any way: a college student checks tickets but lets people in whether or not they have a ticket. The other door has the number 443 on it, and it’s protected by an armed bully letting only qualified people in. The chances of unwanted people getting into the club through door 443 are pretty slim (unless the bully is corrupt), which is not the case with door 80—once in a while, people who have no right to be there get inside.
On a similar note, your organization has created network security with a firewall (the fence) with only two ports (the doors) open: 80 for HTTP requests and 443 for HTTPS. One door is not secure; the other one is.
|
Warning
|
Don’t assume that your web application is secure if it’s deployed behind a firewall. As long as there are open ports that allow external users to access your web application, you need to invest in the application security, too. |
The letter s in HTTPS stands for secure. Technically, HTTPS creates a secure channel over an insecure Internet connection. In the past, only web pages that dealt with logins, payments, or other sensitive data would use URLs starting with https. Today, more and more web pages use HTTPS, and rightly so, because it forces web browsers to use Secure Sockets Layer (SSL) or its successor, Transport Layer Security (TLS) protocol, for encrypting all the data (including request and response headers) that travel between connected Internet resources. High Performance Browser Networking contains a chapter with detailed coverage of the TLS protocol.
Organizations that run web servers create a public-key certificate that has to be signed by a trusted certificate authority (otherwise, browsers will display invalid certificate warnings). The authority certifies that the holder of the certificate is a valid operator of this web server. SSL/TLS layers authenticate the servers by using these certificates to ensure that the browser’s request is being processed by the proper server and not by some hacker’s site.
When a client connects to a server via HTTPS, that client offers to the server a list of supported ciphers (authentication-encryption-decryption algorithms). The server replies with a cipher they both support.
|
Tip
|
The annual Black Hat computer security conference is dedicated to information security. This conference is attended by both hackers and security professionals. |
If HTTPS is clearly more secure than HTTP, why doesn’t every website use only HTTPS communication? Because HTTPS encrypts all messages that travel between the client’s browser and the server, its communications are slower and need more CPU power compared to HTTP-based data exchanges. But this slowness isn’t noticeable in most web applications (unless thousands of concurrent users hit the web server), whereas the benefits of using HTTPS are huge.
When entering any sensitive or private information in someone’s web application, always pay attention to the URL to make sure that it uses HTTPS.
As a web developer, you should always use HTTPS to prevent an attacker from stealing the user’s session ID. The fact that the National Security Agency has broken the SSL encryption algorithm is not a reason for your application to not use HTTPS.
Authentication is the ability to confirm that a user is who he claims to be. The fact that the user has provided a valid ID and password combination proves only that he is known to the web application. That’s all.
Specifying the correct user ID/password combination might not be enough for some web applications. Banks often ask for additional information (for example, "What’s your pet’s name?" or "What’s your favorite movie?").
Large corporations often use RSA SecurID (a.k.a. RSA hard token), which is a physical device with a randomly generated combination of digits. This combination changes every minute or so and has to be entered as a part of the authentication process. In addition to physical devices, programs (soft tokens) can perform user authentication in a similar way. Many financial institutions, social networks, and large web portals support two-factor verification: in addition to asking for a user ID and password, they send you an email, voice mail, or text message with a code that you’ll need to use after entering the right ID/password combination.
To make the authentication process more secure, some systems check the biometrics of the user. For example, in the United States, the Global Entry system is implemented in many international airports. People who successfully pass a special background check are entered into the system deployed at passport-control checkpoints. These applications, deployed in a special kiosks, scan users' passports and check the face topography and fingerprints. The process takes only a few seconds, and the authenticated person can pass the border without waiting in long lines.
Biometric devices have become more common these days, and fingerprint scanners that can be connected to a user’s computer are very inexpensive. Apple’s iPhone 5S unlocks based on the fingerprint of its owner—no need to enter a passcode. In some places, you can enter a gym only after your fingerprints have been scanned and matched. The National Institute of Standards and Technology hosts a discussion about using biometric web services, and you can participate by sending an email to [email protected] with subscribe as the subject.
HTTP defines two types of authentication: Basic and Digest. All modern web browsers support them, but basic authentication uses Base64 encoding and no encryption, which means it should be used only with HTTPS.
A web server administrator can configure certain resources to require basic user authentication. If a web browser requests a protected resource but the user didn’t log in to the site, the web server (not your application) sends the HTTP response containing HTTP status code 401 (Unauthorized and WWW-Authenticate: Basic). The browser pops up the login dialog box. The user enters the ID/password, which is turned into an encoded userID:password string and sent to the server as a part of HTTP header. Basic authentication provides no confidentiality because it doesn’t encrypt the transmitted credentials. Cookies are not used here.
With digest authentication, the server also responds with 401 (WWW-Authenticate: Digest). However, it sends along additional data that allows the web browser to apply a hash function to the password. Then, the browser sends an encrypted password to the server. Digest authentication is more secure than the basic one, but it’s still less secure than authentication that uses public keys or the Kerberos authentication protocol.
|
Tip
|
The HTTP status code 403 (Forbidden) differs from 401. Whereas 401 means that the user needs to log in to access the resource, 403 means that the user is authenticated, but his security level is not high enough to see the data. For example, not every user role is authorized to see a web page that displays salary reports. |
In application security, the term man-in-the-middle attack refers to an attacker intercepting and modifying data transmitted between two parties (usually the client and the server). Digest authentication protects the web application from losing the clear-text password to an attacker, but doesn’t prevent man-in-the-middle attacks.
Whereas digest authentication encrypts only the user ID and password, using HTTPS encrypts everything that goes between the web browser and the server.
Often, an enterprise user has to work with more than one corporate web application, and maintaining, remembering, and supporting multiple passwords should be avoided. Many enterprises implement internally a single sign-on (SSO) mechanism to eliminate the need for a user to enter login credentials more than once, even if that user works with multiple applications. Accordingly, signing out from one of these applications terminates the user’s access to all of them. SSO solutions make authentication totally transparent to your application.
With SSO, when the user logs on to your application, the logon request is intercepted and handled by preconfigured SSO software (for example, Oracle Enterprise Single Sign-On, CA SiteMinder, IBM Security Access Manager for Enterprise SSO, or Evidian Enterprise SSO). The SSO infrastructure verifies a user’s credentials by making a call to a corporate Lightweight Directory Access Protocol (LDAP) server and creates a user’s session. Usually a web server is configured with some web agent that will add the user’s credentials to the HTTP header, which your application can fetch.
Future access to the protected web application is handled automatically by the SSO server, without even displaying a logon window, as long as the user’s session is active. SSO servers also log all login attempts in a central place, which can be important in meeting enterprise regulatory requirements (for example, Sarbanes-Oxley in the financial industry or medical confidentiality in the insurance business).
In the consumer-oriented Internet space, single (or reduced) sign-on solutions have become more and more popular. For example, some web applications allow you to reuse your Twitter or Facebook credentials (provided that you’ve logged in to one of these applications) without the need to go through additional authentication procedures. Basically, your application can delegate authentication procedures to Facebook, Twitter, Google, and other authorization services, which we’ll discuss later in OAuth-Based Authentication and Authorization.
Back in 2010, Facebook introduced its SSO solution that still helps millions of people log in to other applications. This is especially important in the mobile world, where users' typing should be minimized. Instead of asking a user to enter credentials, your application can provide a Login with Facebook button.
Facebook has published a JavaScript API with which you can implement Facebook Login in your web applications (it also offers native APIs for iOS and Android apps). For more details, read the online documentation on the FaceBook Login API.
Besides Facebook, other popular social networks offer authentication across applications:
-
If you want your application to have a Login with Twitter button, refer to the Sign in with Twitter API documentation.
-
LinkedIn is a popular social network for professionals. It also offers an API for creating a Sign In with LinkedIn button. For details, visit the LinkedIn online documentation for developers.
-
Google also offers the OAuth-based authentication API. Details about its client library for JavaScript are published online. To implement SAML-based SSO with Google, visit this web page.
-
Mozilla offers a new way to sign in with any of your existing email addresses by using Persona.
-
Several large organizations (for example, Google, Yahoo!, Microsoft, and Facebook) either issue or accept OpenID, which makes it possible for users to sign in to more than 50,000 websites.
Typically, large enterprises don’t want users to use logins from social networks. But some organizations have started integrating their applications with social networks. Especially now, with the spread of mobile devices, users might need to be authenticated and authorized while being outside the enterprise perimeter. We discuss this in more detail in OAuth-Based Authentication and Authorization.
Does our Save The Child application have a use for SSO? Certainly. In this book, we’re concerned mostly about developing a UI for the consumer-facing part of this application. But there is also a back-office team that is involved with content management and that produces information for the consumer.
For example, the employees of our charity organization create fundraising campaigns in different cities. If an employee of this firm logged in to his desktop, our Save The Child web application shouldn’t ask him to log in. SSO can be a solution here.
It might sound obvious, but we’ll still remind you that the web client should never send passwords in clear text. You should always use a Secure Hash Algorithm (SHA). Longer passwords are more secure, because if an attacker tries to guess the password by using dictionaries to generate every possible combination of characters (a brute-force attack), it will take a lot more time with long passwords. Periodically changing passwords makes the hacker’s work more difficult, too. Typically, after successful authentication, the server creates and sends to the web client the session ID, which is stored as a cookie on the client’s computer. Then, on each subsequent request to the server, the web browser places the session ID in the HTTP request object and sends it along with each request. Technically, the user’s identity is always known at the server side, so the server-side code can re-authenticate the user more than once (without the user even knowing it), whenever the web client requests the protected resource.
|
Tip
|
Salted hashes increase security by adding salt—randomly generated data that’s concatenated with the password and then processed by a hash function. |
Have you ever wondered why automated teller machines (ATMs) often ask you to enter your PIN more than once? Say you’ve deposited a check and then want to see the balance on your account. After the check deposit is completed, your ATM session is invalidated to protect careless users who might rush out from the bank in a hurry as soon as the transaction is finished. This prevents the next person at the ATM from requesting a cash withdrawal from your bank account.
On the same note, if a web application’s session is idling for more than the allowed time interval, the session should be automatically invalidated. For example, if a trader in a brokerage house stops interacting with a web trading application for some time, invalidate the session programmatically to prevent someone else from buying financial products on his behalf when he steps out for a coffee.
Authorization is a way to determine which operations the user can perform and what data he can access. For example, the owner of a company can perform money withdrawals and transfers from an online business bank account, whereas the company accountant is provided with read-only access.
|
Note
|
Similar to authentication, the user’s authorization can be checked more than once during that user’s session. As a matter of fact, authorization can even change during a session (for example, a financial application can allow trades only during business hours of the stock exchange). |
Users of an application are grouped by roles, and each role comes with a set of privileges. A user can be given a privilege to read and modify certain data, whereas other data can be hidden. In the relational DBMS realm, the term row-level security means that the same query can produce different results for different users. Such security policies are implemented at the data-source level.
A simple use case for which row-level security is really useful is a salary report. Whereas the employee can see only his salary report, the head of department can see the data of all subordinates.
Authorization is usually linked to a user’s session. HTTP is a stateless protocol, so if a user retrieves a web page from a web server, and then goes to another web page, this second page does not know what has been shown or selected on the first one. In an online store, for example, a user adds an item to a shopping cart and moves to another page to continue shopping. To preserve the data reused in more than one web page (for example, the content of the shopping cart), the server-side code must implement session-tracking. The session information can be passed all the way down to the database level when need be.
|
Note
|
Session tracking is usually controlled on the server side. To become familiar with session tracking options in greater detail, consult the product documentation for the server or technology being used with your web application. For example, if you use Java, you can read Oracle’s documentation for its WebLogic server that describes options for session management. |
To put it simply, OAuth is a mechanism for delegated authorization. OpenID Connect is an OAuth-based mechanism for authentication.
Most likely, you have come across web applications that enable you to share your actions via social networks. For example, if you just made a donation, you might want to share this information via social networks.
If our charity application needs to access a user’s Facebook account for authentication, the charity app could ask for the user’s Facebook ID and password. This wouldn’t be the correct approach, however, because the charity application would get the user’s Facebook ID/password in clear text, along with full access to the user’s Facebook account. The charity app needs only to authenticate the Facebook user. Hence, there is a need for a mechanism that gives limited access to Facebook.
OAuth has become one of the mechanisms for providing limited access to an authorizing facility. OAuth is "An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications." Its current draft specification provides the following definition:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
"OAuth Study Notes" includes the following:
Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk.
This is a good example of limited access to a resource in a real life. The OAuth 2.0 authorization server gives the requesting application an access token (think, valet key) so it can access, say, the charity application.
OAuth allows users to give limited access to third-party applications without giving away their passwords. The access permission is given to the user in the form of an access token with limited privileges and for a limited time. Coming back to our example of communication between the charity app and Facebook (unless we have our own enterprise authentication server), the former would gain limited access to the user’s Facebook account (just the valet key, not the master key).
OAuth has become a standard protocol for developing applications that require authorization. With OAuth, application developers won’t need to use proprietary protocols if they need to add an ability to identify a user via multiple authorization servers.
Wikipedia defines federated identity as a means of linking a person’s electronic identity and attributes, stored across multiple distinct identity management systems. This is similar to enterprise SSO, but the effect of federated identity is broader because the authentication token with information about a user’s identity can be passed across multiple departments or organizations and software systems.
Microsoft’s "A Guide to Claims-Based Identity and Access Control" includes a section on federated identity for web applications with greater details on this subject.
In the past, the markup language SAML was the most popular open-standard data format for exchanging authentication and authorization data. OpenID Connect is a newer open standard. It’s a layer on top of OAuth 2.0 that simply verifies the identity of a user. OpenID providers that can confirm a user’s identity include such companies as Google, Yahoo!, IBM, Verisign, and more. Typically, OpenID Connect uses JSON Web Token (JWT), which should eventually replace popular XML-based SAML tokens. JWT is a Base64 encoded and signed JSON data structure. Although the OAuth 2.0 spec doesn’t mandate using JWT, it became a de facto standard token format.
To have a better understanding of how JWTs are encoded, visit the Federation Lab, which is a website with a set of tools for testing and verifying various identity protocols. In particular, you can enter a JWT in clear text, select a secret signature, and encode the token by using the HS256 algorithm, as shown in Encoding a JSON Web Token.
Facebook is one of the authorization servers that offer an OAuth-based authentication and authorization API. The online document "Quickstart: Facebook SDK for JavaScript" is a good starting point.
Before using the SDK, you need to register your application with Facebook by creating a client ID and obtaining the client secret (the password). Then, use the JavaScript SDK code (provided by Facebook) in your web application. Include the newly created app ID there. During this registration stage, you’ll need to specify the URI where the user should be redirected in case of successful login. Then, add a JavaScript code to support the required Facebook API (for example, for Login) to your application. You can find sample JavaScript code that uses the Facebook Login API in this guide.
The Facebook Login API communicates with your application by sending events as soon as the login status changes. Facebook will send the authorization token to your application’s code. As we mentioned earlier, the authorization token is a secure encoded string that identifies the user and the app, contains information about permissions, and has an expiration time. Your application’s JavaScript code makes calls to the Facebook SDK API, and each of these calls will include the token as a parameter or inside the HTTP request header.
Any communication with OAuth 2.0 servers are made through HTTPS connections. The following are the main actors of the OAuth flows:
-
The user who owns the account with some of the resource servers (for example, an account at Facebook or Google) is called the resource owner.
-
The application that tries to authenticate the resource owner is called the client application. This is an application that offers buttons such as Login with Facebook, Login with Twitter, and the like.
-
The resource server is a place where the resource owner stores his data (for example, Facebook or Google).
-
The authorization server checks the credentials of the resource owner and returns an authorization token with limited information about the user. This server can be the same as the resource server but is not necessarily the same one. Facebook, Google, Windows Live, Twitter, and GitHub are examples of authorization servers. For the current list of OAuth 2.0 implementations, visit oauth.net/2.
To implement OAuth in your client application, you need to pick a resource/authorization server and study its API documentation. Keep in mind that OAuth defines two types of clients: public and confidential. Public clients use embedded passwords while communicating with the authorization server. If you’re going to keep the password inside your JavaScript code, it won’t be safe. To be considered a confidential client, a web application should store its password on the server side.
OAuth has provisions for creating authorization tokens for browser-only applications, for mobile applications, and for server-to-server communications.
We can distinguish two major scenarios of a third-party application working with an OAuth server. In one scenario, OAuth authorization servers are publicly available. In the other scenario, the servers are privately owned by the enterprise. Let’s consider these scenarios in the context of our charity nonprofit organization.
A Facebook account owner works with the client (the Save The Child application). The client uses an external authorization server (Facebook) to request authorization of the user’s work with the charity application. The client has to be registered (has an assigned client ID, secret, and redirect URL) with the authorization server to be able to participate in this OAuth flow. The authorization server returns a token offering limited access (for example, to Facebook’s account) to the Save The Child application. Save The Child and OAuth shows Save The Child using Facebook for authentication and authorization.
While the client application tries to get authorization from the authorization server, it can open a so-called consent window that warns the user that the Save The Child application is trying to access certain information from the user’s Facebook or Google account. In this scenario, the user still has a chance to deny such access. It’s a good idea to display a message that the user’s password (to Facebook or Google) will not be given to the client application.
Your application should request only minimum access to the user’s resource server. For example, if the Save The Child application just needs to offer an easy authentication method for all Facebook users, don’t request write access to the user’s Facebook account. On the other hand, if a child was cured as a result of the involvement of our charity application, and he wants to share the good news with his Facebook friends, the Save The Child application needs write permission to the user’s Facebook account.
The UI code of the Save The Child application doesn’t have to know how to parse the token returned by the authorization server. It can simply pass it to Save The Child’s server software (for example, via the HTTP request header). The server has to know how to read and decipher the information from the token. The client application sends to the authorization server only the client ID, and not the client secret needed for deciphering the user’s information from the token.
The OAuth authorization server is configured inside the enterprise. However, the server can attend to not only internal employees, but also external partners. Suppose that one of the upcoming charity events is a marathon to fight cancer. To prepare this marathon, our charity organization needs the help of a partner company named Global Marathon Suppliers, which will take care of the logistics (providing banners, water, food, rain ponchos, blankets, branded tents, and so forth).
It would be nice if our supplier could have up-to-date information about the number of participants in this event. If our charity firm sets them up with access to our internal authorization server, the employees of Global Marathon Suppliers can have limited access to the marathon participants. On the other hand, if the suppliers open limited access to their data, this could increase the productivity of the charity company employees. This is a practical and cost-saving setup.
|
Note
|
The authors of this book have helped the Leukemia and Lymphoma Society (LLS) develop both front- and backend software. LLS ran a number of successful marathons as well as many other campaigns for charity causes. We also use an OAuth solution from Intuit QuickBooks in billing workflows for our insurance industry software product at SuranceBay. Our partner companies get limited access to our billing systems, and our software can access theirs. |
The Open Web Application Security Project (OWASP) is an open source project focused on improving security of web applications by providing a collection of guides and tools. OWASP publishes and maintains a list of the top 10 security risks. Top 10 security risks, circa 2013 shows how this list looked in 2013.
On this website, you can drill down into each list item to see the selected security vulnerabilities and recommendations on how to prevent them. You can also download this list as a PDF document. Let’s review a couple of the top-10 security threats: injection and cross-site scripting.
If a bad guy can inject a piece of code that will run inside your web application, that code could steal or damage data from the application. In the world of compiled libraries and executables, injecting malicious code is a rather difficult task. But if an application uses interpreted languages (for example, JavaScript or clear-text SQL), the task of injecting malicious code becomes a lot easier than you might think. Let’s look at a typical example of SQL injection.
Suppose that your application can search for data based on keywords a user enters into a text input field. For example, to find all donors in the city of New York, a user enters the following:
"New York"; delete from donors;
If the server-side code of your application simply attaches the entered text to the SQL statement, this could result in execution of the following command:
Select * from donors where city="New York"; delete from donors;
This command doesn’t require any additional comments, does it? Is there a way to prevent users of your web application from entering something like this? The first thing that comes to mind is to not allow the user to enter the city, but force her to select it from a list. But such a list of possible values might be huge. Besides, the hacker can modify the HTTP request after the browser sends it to the server.
|
Tip
|
Always use precompiled SQL statements that use parameters to pass the user’s input into the database query (for example, PreparedStatement in Java). |
The importance of server-side validation shouldn’t be underestimated. In some scenarios, you can come up with a regular expression that checks for matching patterns in data received from clients. In other cases, you can write a regular expression that invalidates data if it contains SQL (or other) keywords that lead to modifications of data on the server.
|
Tip
|
Always minimize the interval between validating and using the data. |
In an ideal world, client-side code should not even send nonvalidated data to the server. But in the real-world, you’ll end up duplicating some of the validation code in both the client and the server.
Cross-site scripting (XSS) occurs when an attacker injects malicious code into a browser-side script of your web application. The user is accessing a trusted website, but gets an injection from a malicious server that reaches the user via the trusted server (hence, cross-site). Single-page Ajax-based applications make lots of under-the-hood requests to servers, which increases the attack surface compared to traditional legacy websites that download web pages a lot less frequently. XSS can happen in three ways:
- Reflected (a.k.a. phishing)
-
The web page contains a link that seems valid, but when the user clicks it, the user’s browser receives and executes the script created by the attacker.
- Stored
-
The external attacker manages to store a malicious script on a server that hosts someone’s web application, so every user gets the script as a part of that web page, and their web browser executes it. For example, if a user’s forum allows posting texts that include JavaScript code, malicious code typed by a "bad guy" can be saved in the server’s database and executed by users' browsers visiting this forum afterward.
- Local
-
No server is involved. Web page A opens web page B with malicious code, which in turn modifies the code of page A. If your application uses a hash tag (#) in URLs (for example, http://savesickchild.org#something), make sure that before processing, this something doesn’t contain anything like _javascript:somecode_, which might have been attached to the URL by an attacker.
The World Wide Web Consortium (W3C) has published a draft of the Content Security Policy document, "a mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting."
Microsoft has published a classification that divides security threats into six categories (hence six letters in the acronym STRIDE):
- Spoofing
-
An attacker pretends to be a legitimate user of an application (for example, a banking system). This can be implemented by using XSS.
- Tampering
-
Modifying data that was not supposed to be modified (for example, via SQL injection).
- Repudiation
-
The user denies sending data (for example, making an online transaction such as a purchase or sale) by modifying the application’s logfiles.
- Information disclosure
-
An attacker gains access to classified information.
- Denial of service (a.k.a. DoS)
-
A server is made unavailable to legitimate users, which often is implemented by generating a large number of simultaneous requests to saturate the server.
- Elevation of privilege
-
Gaining an elevated level of access to data (for example, by obtaining administrative rights).
|
Note
|
While we were working on a section of this book describing Apple’s developer certificates ([epilog]), its website was hacked, and was not available for about two weeks. |
|
Important
|
One of the OWASP guides is titled Web Application Penetration Testing. In about 350 pages, it explains the methodology of testing a web application for each vulnerability. OWASP defines penetration test as a method of evaluating the security of a computer system by simulating an attack. Hundreds of security experts from around the world have contributed to this guide. Running penetration tests should become part of your development process, and the sooner you start running them, the better. |
For example, the Payment Card Industry published a Data Security Standard, which includes a Requirement 11.3 of penetration testing.
So far in this chapter, we’ve been discussing security vulnerabilities from a technical perspective. But another aspect can’t be ignored: the regulatory compliance of the business you automate.
During the last four years, the authors of this book have developed, deployed, supported, and marketed software that automates certain workflows for insurance agents. We serve several hundred insurance agencies and more than 100,000 agents. In this section, we’ll share our real-world experience of dealing with security while running our company, which sells software as a service. In addition to developing the application, we had to set up data centers and take care of security issues, too.
Our customers are insurance agencies and carriers. We charge for our services, and our customers pay by using credit cards via our application. This opens up a totally different category of security concerns:
-
Where are the credit card numbers stored?
-
What if they are stolen?
-
How secure is the payment portion of the application?
-
How is the card holder’s data protected?
-
Is there a firewall protecting each customer’s data?
-
How is the data encrypted?
One of the first questions our prospective customers ask is whether our application is PCI compliant. They won’t work with us until they review the application-level security implemented in our system. As per the PCI Compliance Guide, "The Payment Card Industry Data Security Standard is used by all card brands to assure the security of the data gathered while an employee is making a transaction at a bank or participating vendor."
If your application stores PCI data, authenticating via Facebook, Google, or a similar OAuth service isn’t an option. Users are required to authenticate themselves by entering long passwords containing combinations of letters, numbers, and special characters.
Even if you are not dealing with credit card information, there are other areas where application data must be protected. Take a human resources application—Social Security numbers (unique IDs of United States citizens) of employees must be encrypted.
Some of our prospective customers send us a questionnaire to establish whether our security measures are compliant with their requirements. In some cases, this document can include as many as 300 questions.
You might want to implement different levels of security depending on which type of device is being used to access your application—a public computer, an internal corporate computer, an iPad, or an Android tablet. If a desktop user forgets his password, you could implement a recovery mechanism that sends an email to that user and expects to receive a certain response from him. If the user has a smartphone, the application could send a text message to that device.
If the user’s record contains both his email and cell phone number, the application should ask where to send the password recovery instructions. If a mobile device runs a hybrid or native version of the application, the user could be automatically switched to a messaging app of the device so that he can read the text message while the main application remains at the view where authentication is required.
In enterprise web applications, more than one layer of security must be implemented: at the communication protocol level, at the session level, and at the application level. The HTTP server NGINX, besides being a high-performance proxy server and load balancer, can serve as a security layer, too. Your web application can offload authentication tasks and validation of SSL certificates to NGINX.
Most enterprise web applications are deployed on a cluster of servers, which adds another task to your project plan: how to manage sessions in a cluster. The user’s session has to be shared among all servers in a cluster. High-end application servers might implement this feature out of the box. For example, an IBM WebSphere server has an option to tightly integrate HTTP sessions with its application security module. Another example is Terracotta clusters, which utilize Terracotta Web Sessions to allow sessions to survive node hops and failures. But small or mid-sized applications might require custom solutions for distributed sessions.
|
Tip
|
Minimize the amount of data stored in a user’s session, to simplify session replication. Store the data in an application cache that can be replicated quickly and efficiently by using open source or commercial products (for example, JGroups or Terracotta). |
Here’s another topic to consider: multiple data centers, with each one running a cluster of servers. To speed up the disaster recovery process, your web application has to be deployed in more than one data center, located in different geographical regions. User authentication must work even if one of the data centers becomes nonoperational.
An external computer (for example, a NGINX server) can perform token-based authentication, but inside the system, the token is used only when access to protected resources is required. For example, when the application needs to process a payment, it doesn’t need to know any credit card details; it just uses the token to authorize the transaction of the previously authenticated user.
This grab bag of security considerations mentioned in this section is not a complete list of security-related issues to which your IT organization needs to attend. If you work for a large enterprise on intranet applications, these security issues might not sound overly important. But as soon as your web application starts serving external Internet users, someone has to worry about potential security holes that were not in the picture for internal applications. Our message to you is simple: Take security very seriously if you are planning to develop, deploy, and run a production-grade enterprise web application.
Every enterprise web application has to run in a secure environment. The mere fact that the application runs inside a firewall doesn’t make it secure. First, if you’re opening at least one port to the outside world, malicious code can sneak in. Second, an "angry employee" or just a "curious programmer" inside the organization could inject unwanted code.
Proper validation of received data is very important. Ideally, use white list validation to compare user input against a list of allowed values. Otherwise, use black list validation to compare against keywords that are not allowed in data entered by users.
There is no way to guarantee that your application is 100 percent protected from security breaches. But you should ensure that your application runs in an environment with the latest available patches for known security vulnerabilities. For example, if your application includes components written in the Java programming language, install critical security patches as soon as they become available.
With the proliferation of clouds, social networks, and sites that offer free or cheap storage, people lose control over security, hoping that Amazon, Google, or Dropbox will take care of it. Besides software solutions, software-as-a-service providers deploy specialized hardware—security appliances that serve as firewalls, perform content filtering, and virus and intrusion detection. Interestingly enough, hardware security appliances are also vulnerable.
In any case, end users upload their personal files without thinking twice. Enterprises are more cautious and prefer private clouds installed on their own servers, where they administer and protect data themselves. Users who access the Internet from their mobile devices have little or no control over how secure their devices are. So the person in charge of the web application has to make sure that it’s as secure as possible.