Chapter Four: Web Services Security

What Is Web Service Security?

Web service security, also known as cybersecurity entails the methodologies involved in protecting a
website or web application.

Because of its nature (loosely coupled connections) and its use of open access (mainly HTTP), SOA
implemented by Web services adds a new set of requirements to the security landscape. Web services
security includes several aspects:

 Authentication—Verifying that the user is who she claims to be. A user's identity is verified
based on the credentials presented by that user, such as:
1. Something one has, for example, credentials issued by a trusted authority such as a
passport (real world) or a smart card (IT world).
2. Something one knows, for example, a shared secret such as a password.
3. Something one is, for example, biometric information.

Using a combination of several types of credentials is referred to as "strong" authentication, for

example using an ATM card (something one has) with a PIN or password (something one
knows).

 Authorization (or Access Control)—Granting access to specific resources based on an

authenticated user's entitlements. Entitlements are defined by one or several attributes. An
attribute is the property or characteristic of a user, for example, if "Marc" is the user,
"conference speaker" is the attribute.
 Confidentiality, privacy—Keeping information secret. Accesses a message, for example a
Web service request or an email, as well as the identity of the sending and receiving parties in a
confidential manner. Confidentiality and privacy can be achieved by encrypting the content of
a message and obfuscating the sending and receiving parties' identities.
 Integrity, non repudiation—Making sure that a message remains unaltered during transit by
having the sender digitally sign the message. A digital signature is used to validate the
signature and provides non-repudiation. The timestamp in the signature prevents anyone from
replaying this message after the expiration.

Web services security requirements also involve credential mediation (exchanging security tokens in a
trusted environment), and service capabilities and constraints (defining what a Web service can do,
under what circumstances).

In many cases, Web services security tools such as Oracle WSM rely on Public Key Infrastructure
(PKI) environments. A PKI uses cryptographic keys (mathematical functions used to encrypt or
decrypt data). Keys can be private or public. In an asymmetric cipher model, the receiving party's
public key is used to encrypt plaintext, and the receiving party's matching private key is used to
decrypt the ciphertext. Also, a private key is used to create a digital signature by signing the message,
and the public key is used for verifying the signature. Public-key certificates (or certificates, for short)
are used to guarantee the integrity of public keys.
Web services security requirements are supported by industry standards both at the transport level
(Secure Socket Layer) and at the application level relying on XML frameworks.

Transport-level Security

Secure Socket Layer (SSL), otherwise known as Transport Layer Security (TLS), the Internet
Engineering Task Force (IETF) officially standardized version of SSL, is the most widely used
transport-level data-communication protocol providing:

 Authentication (the communication is established between two trusted parties).

 Confidentiality (the data exchanged is encrypted).
 Message integrity (the data is checked for possible corruption).
 Secure key exchange between client and server.

SSL provides a secure communication channel, however, when the data is not "in transit," the data is
not protected. This makes the environment vulnerable to attacks in multi-step transactions. (SSL
provides point-to-point security, as opposed to end-to-end security.)

Application-level Security

Application-level security complements transport-level security. Application-level security is based on

XML frameworks defining confidentiality, integrity, authenticity; message structure; trust
management and federation.

Data confidentiality is implemented by XML Encryption. XML Encryption defines how digital
content is encrypted and decrypted, how the encryption key information is passed to a recipient, and
how encrypted data is identified to facilitate decryption.

Data integrity and authenticity are implemented by XML Signature. XML Signature binds the sender's
identity (or "signing entity") to an XML document. Signing and signature verification can be done
using asymmetric or symmetric keys.

Signature ensures non-repudiation of the signing entity and proves that messages have not been altered
since they were signed. Message structure and message security are implemented by SOAP and its
security extension, WS-Security. WS-Security defines how to attach XML Signature and XML
Encryption headers to SOAP messages. In addition, WS-Security provides profiles for 5 security
tokens: Username (with password digest), X.509 certificate, Kerberos ticket, Security Assertion
Markup Language (SAML) assertion, and REL (rights markup) document.

The SOAP envelope body includes the business payload, for example a purchase order, a financial
document, or simply a call to another Web service. SAML is one of the most interesting security
tokens because it supports both authentication and authorization. SAML is an open framework for
sharing security information on the Internet through XML documents. SAML includes 3 parts:

 SAML Assertion—How you define authentication and authorization information.

 SAML Protocol—How you ask (SAML Request) and get (SAML Response) the assertions you
need.
  SAML Bindings and Profiles—How SAML assertions ride "on" (Bindings) and "in" (Profiles)
industry-standard transport and messaging frameworks.

The full SAML specification is used in browser-based federation cases. However, web services
security systems such as Oracle WSM only use SAML assertions. The protocol and bindings are taken
care of by WS-Security and the transport protocol, for example HTTP.
SAML assertions and references to assertion identifiers are contained in the WS-Security Header
element, which in turn is included in the SOAP Envelope Header element (described in the WS-
Security SAML Token Profile). The SAML security token is particularly relevant in situations where
identity propagation is essential.

Why Do We Need To Protect Our Web Services?

Failing to secure web services can result in serious consequences for the user as well as the service itself.
As an illustration, one coding hosting service was victim to a breach in which an attacker gained unauthorized
access to their Amazon Web Services account. The result of this failure was more than just a fine. The
company, called Code Spaces, had to close shop permanently.
The costs associated with such a web service security blunder as well as Coding Spaces’s initial disregard for
creating an effective recovery plan proved to be at the root of its detriment. The hacker had already deleted
valuable data and content. This is just one instance of how web security, or a lack thereof, affected dire
circumstances on a company’s success.

All small businesses face the same risk.

This, of course, does not even begin to scratch the surface of the customers whose information was put in
jeopardy in the process.

Successful businesses are built on good reputations and healthy consumer relationships. Ineffective web
service security will not garner that effect.
Ways to Secure Your Web Service

The idea that web service security is a necessary precaution has been well-established.
Now, if you’re wondering how to secure your web services, pay attention to the 8 strategic ways listed below, to
put cybersecurity at the forefront of your business goals.
1. Don’t Trust Your Client
There is no way of knowing whether our users have good intentions or not. For vigilant web service security
protocol, we should not trust any data inputted by our customer. This means that we need to check every input.
We can do it with a blacklist or a whitelist.
In a blacklist, we have bad inputs that are deemed unacceptable as user inputs. In a whitelist, we have
inputs that we allow to exist. Let’s take a look at an example.
We know that eval() is a function that executes strings as commands in Javascript. Surely, a user with good
intentions wouldn’t use this kind of content as an email. So, we will replace every eval() to be empty.

This can be helpful, however with every new threat we have to check our code and clean it up.
So for this stage, whitelists are more reliable than blacklists. We have awesome libraries that help us to create
quick whitelists checks in our routes, for example, Hapi/JOI.

Look at this example, where we check the inputs for user authentication:

The example above is awesome because this library will guarantee us two things:

1. A good whitelist with good standards. If the input doesn’t fit with our standards, the new Error() will be
triggered.
2. Protection against Parameter Injection, which means that the hacker tries to send more parameters to
our routes. If there exists any different parameter besides email and password, the new Error() will be
triggered;

In our example, the only parameters allowed are email and password, and they must adhere to our standards.

Don’t forget to use whitelists, they’re very helpful for web service security! They can help against
Parameter Injection and XSS.

2. Use Bind-Params in Your SQL Statements

You’ve probably heard about SQL Injections, and how powerful they can be. If you haven’t heard about them
then I suggest you read about them. In addition, check OWASP Top Ten Attacks. But essentially, an attacker
tries to change the queries that the system makes and gets access to the entire database.
I will never forget the day I was talking about SQL Injection breaches with one of my co-workers. He
challenged me to access a system that he made for his friend through a SQL Injection attack. This system didn’t
use the bind params, so I got the admin user and I put into the password field a well-known SQL Injection
command to bypass the password for any user, and voilá! I got admin access.
Now, thinking back to this story, I feel that I should have bet on a beer with him. The most simple solution is to
use bind params. Bind params change the values inside of the database making it impossible to break the
query and change to another one.
Nowadays, most ORMs use bind params as default but deliberately do not make a custom query and execute it
without bind params.
For example, in Node.JS + Sequelize, if we want to use a custom query, we could do something like:

The image above shows two methods. The first method is an example with a custom query without bind params
and the second is one with a custom query using bind params. You might’ve guessed right – the second method
is the better one. If you have to use custom queries, then please, don’t forget to use the bind params. Also,
ensure that your ORM uses them too. I know Sequelize does this by watching the logs, and I know the most
famous ORMs are using them. But if you’re the kind of person that loves to try new technologies and libraries,
this is a good point to start wondering whether that ORM is good or not.
Therefore, don’t use any kind of query without bind params. SQL Injection is considered one of the most
famous of the top ten attacks on web applications, and it was discovered in the ’90s.
It shows how negligent the most developers and engineers have been.
I still don’t know why we don’t teach developers to use bind params since the first class to connect on the
database and make queries.

3. Don’t Expose Sensitive Data

How often does your web service handle sensitive data?

If you never asked yourself this question, your web service likely exposes more sensitive data than you think.
The first step is to apply an SSL/TLS certificate on our web service and use it as the default connection. We
can’t accept HTTP connections anymore for systems that use our personal information!
This certificate ensures that we have an encrypted connection between servers and customers, which
almost mitigates “data sniffing” from a third party. This prevents a man-in-the-middle attack.
Next, ask yourself: How are you helping hackers access your information? By showing system errors to them!
Errors can sometimes display a lot of sensitive information, such as the database system, table names,
field names, constraint names, programming languages, and more.
Sometimes we can even see hosting information and passwords. When that happens, it gives hackers a means of
exploring the known security breaches for the technology, systems, frameworks, and programming languages
that your web service works with. I can’t stress this one point enough. Do not show errors to users.
We need to intercept them and send them to programs like Rollbar or Sentry. These programs have great
support for many languages. Not to mention it’s pretty simple to configure your exceptions to show a default
message to the user and send the system error to those tracker programs.
Altogether, it’s best to show the user a default error message or a descriptive user-friendly error message instead
of showing the whole system error.
A great example of a default error message is “Internal Server Error”. It’s much safer for a system to show
this rather than the whole system error.
4. Check Your Third-Party Libraries
I mentioned before that Equifax will pay up to $700 million in fines. Could you imagine your company being
responsible for a huge data breach like that?
So, what happened with Equifax? Well, it’s not a complicated story to tell. Equifax had a system that used
Apache Struts. Two months before the attack, Apache Struts had announced a new patch to fix a specific
vulnerability. Two months later, the hacker was exploiting this vulnerability, meaning that Equifax didn’t
update their systems.

This was the result:

 https://www.youtube.com/watch?v=e6fIuRqu6wc
 https://www.youtube.com/watch?v=V38eMXbK7gg

To prevent this kind of problem, we have to look at our third-party libraries. Nowadays, it’s almost impossible
to create any application without using any third-party library or framework.
But one has to ask, who made that library? How well managed is it? We are human beings and we make
mistakes. Therefore, as a developer, it is your responsibility to manage the integrations you use.
This means assess their risks, understand the potential effects it can have on your system, and stay up to
date on any updates.
There’s a fantastic tool called Snyk, which keeps developers alert to failures, vulnerabilities, and problems with
your integrations.
Snyk has a huge database with a lot of contributors and when they find a new vulnerability, they warn all their
customers that use Snyk in their applications. Most of the time they fix the new vulnerabilities automatically
with one command that you need to run. Also, Snyk warns you via your email. Snyk is a truly incredible tool
when it comes to web service security!

I personally love how companies are working hard to give consumers outstanding value, especially when it
comes to security. That’s why their valuation surpasses one billion dollars. They also have free plans and priced
plans. Currently, I use the free plan for my personal projects. They support many languages and package
managers.
5. Set Limits for the User
I’m very enthusiastic about cryptocurrencies and Bitcoin, and I talk more about the usage of blockchain on
Trio’s blog. I remember witnessing the exchange falling because Bitcoin’s price was rising too fast. After the
owner lost a lot of money, they decided to invest more in architecture and introduced a new feature to their
APIs: limits to the client. In the exchange, to guarantee good performance, they send a new result every minute.
If you request the same route several times in that same minute, you’ll get the same cached result. It’s a great
way to ensure more performance and to decrease the chances of your server falling down. Of course, we have to
study and analyze the business impacts of caching the response every minute.
Using a layer to protect your service from DDoS attacks such as Cloudflare is also a great idea, and we
can combine their solution with a good architecture on our APIs. This is actually what the exchange did. They
combined a cached result with Cloudflare DDoS protection.

6. Read the Security Section in the Manual of Your Library

Apparently, we are reading less and less, generation after generation. Also, we’re having problems paying
attention for extended periods of time. As a software engineer, I know that patience, attention, and reading are
big facets of our daily routine. Ergo, it’s vital that we discipline ourselves and read the documentation from
our frameworks and third libraries, including the security section.
By using Express, I’ve noticed that we have a section called “Advanced Topics” and “Security Best Practices”.
This is awesome. But I know that most software engineers that have installed Express haven’t read the Express
documentation and probably never bothered diving into the “Advanced Topics” section, much less the “Security
Best Practices” page. Reading is probably the easiest way to familiarize yourself with the base tenets of web
service security. To my surprise, when I decided to implement Express in one of my APIs, I saw this section
and found that Express offers wonderful documentation on how to protect your web service with Express.
With that documentation, I was able to learn how to use Express in a way that did not compromise my
system in the future.
7. Don’t Be Paranoid and Continue to Study Security
After studying security for my applications and web services, I started to go a little crazy! I couldn’t finish my
tasks on time because I was thinking too much about all of the potential security breaches in my code.
We have to remember that even big organizations like the CIA, Sony, eBay, Yahoo, JP Morgan Chase,
Netshoes, Dropbox, and YouTube, have been hacked. Considering that, don’t be so paranoid about your
services. After all, if the hackers really want to hack your application, they probably will find a way.
It’s just in their nature. The real question is: how much time do you need to identify that a hacker bypassed your
security barriers?
With good logs and strong alerts strategy, we can identify breaches sooner and thus act on them quicker.
This is not an excuse to tell yourself that it’s pointless because hackers will win. Developers and cybersecurity
professionals work to build as many walls, mazes, traps and other defenses for hackers to become discouraged
and leave their system alone. So it’s best to make the hacker’s job as difficult as possible in hope that they will
move on to their next target. Also, don’t neglect to study web service security. This article covers the most
basic webs service security techniques. However, we should be learning these approaches in college or in
beginner tutorials on the Internet. Most developers are not interested in protecting their services at a basic level.
That’s a problem.
Again, don’t be consumed with paranoia. At the same time, continue to study and invest time in protecting your
applications. A good resource to study is the OWASP page, especially the projects page. You can download the
“Lab” projects and attempt to hack the software yourself. These projects have security breaches implemented on
purpose. It’s fun to learn in this way where you’re in the position of the hacker and the software engineer is
trying to stop your attack.
This form of web services security testing is similar to a coding challenge. The Node.JS project OWASP
learning environment is called NodeGoat. There’s a tutorial guide to help you hack and protect the project.
There are projects in other programming languages as well. It’s worth taking a look at them. The only way to
truly find ways to stop a hacker is to think like one and break your own system. This is the fundamental idea
of penetration testing, which is a major player in web service security.
8. Logs and Monitoring
There are some situations where we need to audit our data to answer questions like “Who edited this line?” or
“What’s making our server so slow? These are key questions to ask in regards to web service security.
We can’t answer these questions if we don’t have good logs. That could be dangerous to any company,
including if a company needs to identify a user with bad intentions. Imagine the following situation:
Someone hacked your web service to process payments from the clients. And your boss asks, “How did the
hacker pass through our security barriers?” This could be a tough question if you don’t have good logs to start
your investigation with. I doubt any executive is trying to hear that there weren’t any logs and therefore there is
no way of knowing. That wouldn’t get you very far. Remember to make logs and make sure you have a system
in place to keep track of them. These are only a few of the strategies you can use to ensure that your web service
is secure.
Like mentioned, you should take the time to do your own research and study up on best practices for web
service security.
How to Secure a REST Web Service
From basic authentication to JSON web tokens—four ways to implement user authorization in a
nutshell.

Contentsexpand
REST is a modern architectural style that defines a new approach to designing web services. Unlike its
predecessors, HTTP and SOA, it’s not a protocol (read: a strict set of rules), but rather a number of
recommendations and best practices of how web services should communicate to each other and how
to secure REST services. The services that are developed in compliance with the best REST practices
are called “RESTful web services.” Security is a cornerstone of RESTful web services. One of the
ways to enable it is a proper in-built user authentication and authorization mechanism.
There are lots of ways to implement user authentication and authorization within the RESTful web
services. The main approaches (or standards) we are going to talk about today are the following:
 Basic authentication
 OAuth 2.0
 OAuth 2.0 + JWT
To make our discussion more specific, let’s assume that we have microservices on the backend of our
application, and upon each user request, several services at the backend have to be called to collect the
requested data. Thus, we will examine each standard not only in terms of security issues, but also in
the context of additional traffic and server load they generate.
Common API Security Challenges
Since nothing is perfect in this world, security implementation in RESTful web services has some
points to consider before starting working on them.
DOS attacks
A Denial of Service (or DOS) attack implies that an attacker sends an overwhelming number of
messages with requests that have an invalid return address. RESTful API can easily shut down
because of it. Despite the fact that your API may not be revealed to the public, it still can suffer from
DOS attacks. Since such an attack can damage the access to the API for everyone—your clients,
partners, apps, devices, and more), you should pay a lot of attention to security.
Farming
There are plenty of websites that use information from other sources to show the client the best buying
deals, for example. To do that, they may take advantage of other services’ APIs to accumulate
information. That is what farming looks like. When you implement authentication, it prevents your
API from exploitation and overloading.
Man-In-The-Middle
When this type of attack happens, a hacker is located right between a sender and a recipient. It can be
a transparent attack or the hacker can pretend to be one of the parties. The final goal is to get access to
unencrypted information. Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols
can save the day here. The right configuration of TLS/SSL can provide secure and clear
communication between a client and a server.
Now, let’s talk about the standards of REST security in more detail.
Basic authentication
The oldest and the simplest standard on the list.
What it looks like: username + password + Base64 (a basic algorithm of hashing usernames and
passwords).
How it works: Imagine that a user tries to log into their Facebook account to access feed, instant
messages, friends, and groups, which are all separate services. After the user inserts their username
and password, the system knows they are allowed to enter and lets them in. However, it doesn’t know
by default what are their roles and privileges, what services they are allowed to access, etc. So every
time the user tries to access any service, the system should once again verify if they are allowed to do
this, which implies an additional call to the authentication server. As far as there are four services in
our example, there will be four additional calls per user in this case. Now imagine that we have 3K
user requests per second, though in case of Facebook 300K sounds more realistic. Multiplying them by
four services, we will end up with 12K calls to the authentication server per second.
Summary: bad scalability, a huge amount of additional traffic that does not bring business value,
significant load on the server.
OAuth 2.0
What it looks like: username + password + access token + expiration token
How it works: The main idea of the OAuth 2.0 standard is that after a user logs into the system with
their username and password, a client (a device the person uses to access the system) receives a pair of
tokens, which are an access token and a refresh token. The access token is used to access all services
in the system. After it expires, the system uses the refresh token to generate a new pair of tokens. So, if
a user enters the system every day, the tokens will also be updated every day, and there will be no
need to log into the system with username and password every time. The refresh token also has its
expiration period (though it's much longer than the one of the access token), and if a user hasn't
entered the system for—let's say—a year, they are likely to be asked to insert the username and
password again. The OAuth 2.0 standard came to replace the basic authentication approach, and it has
certain advantages, such as that a user doesn't have to insert username and password every time they
want to enter the system. However, the system still needs to make calls to the auth server, as in the
case with the basic auth approach, to check what what the user who owns the token is authorized to do.
Let's imagine that the expiration date is one day. That implies significantly less load on the login
server, because a user has to insert their credentials only once a day, not every time they want to enter
the system. However, the system still needs to verify each token and to check out the user roles as well
as store state somewhere. So, we again end up with multiple calls to the authentication server.
 Summary: same issues as with the basic authentication approach—bad scalability and a huge load on
the authentication server.
OAuth 2 + JSON Web Tokens
What it looks like: username + password + JSON map + Base64 + private key + expiration date
How it works: When a user logs into the system with their username and password for the first time,
the system returns back not just an access token, which is simply a string, but a JSON map containing
all user information, such as roles and privileges, encoded with Base64 and signed with a private key.
This is how it looks with and without encoding:

Looks scary, but this actually works! The main difference is that we can store state in the token, while
services stay stateless. This means that the users themselves hold their own info and there is no need
for additional calls to retrieve it as everything is already inside the token. And this is a huge deal in
reducing the load on the server. This standard is widely used all over the world.
Summary: good scalability, works fine with microservices.
How to apply security on RESTful web services
We listed possible ways to secure your REST web service. Here are some more tips that will help you
enhance the security level even more:
 HTTPS protocols will keep all your communication safe.
 The higher the level of encryption for all elements, the better.
 Sending any credentials and keys as query parameters is dangerous since they will be displayed as a part of
the URL.
 Always validate the input data. Always.