Web Services and Security

Web Services and security
SAIT 205
Web services
• Web service is a standardized medium to propagate communication
between the client and server applications on the World Wide Web.
• Web services provide a common platform that allows multiple
heterogenous applications built on various programming language to have
the ability to communicate to one another.
• There are mainly two types of web services: SOAP web services and RESTful
web services.
• Soap(Simple object access protocol) is a messaging protocol specification
for exchanging structured information in the implementation of web
services in computer networks.
• A REST API is an application programming interface that conforms to the
constrains of REST architectural style and allows for interaction with
RESTful web services.
Web Services
SOAP Web services
• This is based onsta simple client server connection model. This came into play during the internet
boom of the 21 century, the server needed to respond to thousands of requests.
• The server must be aware of what is happening with the client and this can be handled in two ways:
• Stateful: server must keep the information that it receives from the client across multiple
requests(stores the client information). Churning of messages.
• This may be crucial in situations involving multiple parties and complex transactions example bank
transactions and flight bookings(heavy on the server.
• Stateless: Each message contains enough information about the state of the client so that the
server don’t need to be bothered about it. Once the server returns the requested data it forgets
about the clients. Each request is isolated from the previous one.
• Stateless operations helps to reduce server load and increase speed of communication.
• Soap is designed to be , operating system, platform independent and is based on xml.
Soap message structure
• A soap message is encoded as
an XML document, consisting
of an <Envelope> element
which contains an optional
<Header> element and a
mandatory <Body> element.
• The <Fault> element,
contained in the <Body> is
used for reporting errors.
• Task 1: Install soap UI
Why REST API
• Consider a movie booking application where you book for a movie for both
online and offline(box office) viewing.
• The application reserves your movie, the time of the movie and the seat
number for the movie.
• In such an application data is never static ,they is a lot of input data and
data keeps on changing every time. The movie titles, time and seats keep
on changing daily and is updated on a regular bases.
• In a client server architecture a client can send a request and the server
send a response/ returns data in the form of a structured data either in the
JSON Format or XML Format.
• These two formats has a proper structure in which data can be
represented.
JSON AND XML FORMAT
• XML FORMAT
<city>
<movies>
<category>coming soon</category>
</movies>
</city>
• JSON FORMAT
{‘city’:{
‘movies’:{
‘category’: ‘coming soon’
}
}
The problem
• You need to put in a lot of methods(Request Object, Response
Object) to retrieve the data.
• Too much work to be done to get the response/ return the data and
considering that you are doing this continuously this becomes
cumbersome.
• This where the REST API comes into play .
What is REST API
• Representational State Transfer
• You can create an object on the server side and return the values of an
object in response to the user.
• Will the movie Mukadota shown in the movie house situated at the
Westgate mall tomorrow afternoon at 2 p.m.?
• When a client sends a request to the server, rest API creates an object on
the server of these particular request and it finds whether the info is
available. It searches for the data on the server for the client. If it finds out
the data is present , it sends the response back to the client with the values
of that particular object.
• You are creating an object and you have the values of an object . The
values of the object are send to the client. This is the state of the object
being send to the client.
REST
• Each and every time you don’t need to generate a new object.
• You just need to pass the state of that object to the client.
• Object to be passed to the client
▪ City
▪ Movie name
▪ Place
▪ Timing
• Since you are passing the state of an object that’s when the term
Representational State Transfer comes in.
REST
• REST is an architectural style as well as an approach for
communications purpose that is often used in various web services
development.
• It is often regarded as the language of the internet
• It is a stateless client and server model
Conceptual Overview
Representational State Transfer (REST)
• Representational State Transfer (REST)

• A style of software architecture for distributed hypermedia systems such as the
World Wide Web.
• REST is basically client/server architectural style
• Requests and responses are built around the transfer of "representations" of
"resources".
• Architectural style means
• Set of architectural constraints.
• Not a concrete architecture.
• An architecture may adopt REST constraints.
• HTTP is the main and the best example of a REST style implementation
• But it should not be confused with REST
Conceptual Overview
Major REST principles
• Information is organized in the form of resources

• Sources of specific information,
• Referenced with a global identifier (e.g., a URI in HTTP).
• Components of the network (user agents and origin servers) communicate via a
standardized interface (e.g., HTTP)
• exchange representations of these resources (the actual documents conveying the information).
• Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the
request, but each does so without being concern about anything but its own request
• an application can interact with a resource by knowing two things: the identifier of the resource and
the action required
• no need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else
between it and resource
• The application needs to understand the format of the information (representation) returned.
Conceptual Overview
REST Architectural Constrains (1)
• Client-server
• Separation of concerns
• Clients are separated from servers by a uniform interface.
• Networking
• Clients are not concerned with data storage, which remains internal to each server, so
that the portability of client code is improved. Servers are not concerned with the user
interface or user state, so that servers can be simpler and more scalable.
• Independent evolution
• Servers and clients may also be replaced and developed independently, as long as the
interface is not altered.
Conceptual Overview
• Stateless communication
• Scalability, reliability
• No client context being stored on the server between requests. Each request from any
client contains all of the information necessary to service the request.
• Resources are conversationally stateless
• Any conversational state is held in the client.
• Uniform Interface
• Simplicity (vs. efficiency)
• Large-grained hypermedia data transfer
• Example: Create, Retrieve, Update, Delete
Conceptual Overview
• Caching
• Efficiency, scalability
• Well-managed caching partially or completely eliminates some client-server interactions,
further improving scalability and performance.
• Consistency issues
• As on the World Wide Web, clients are able to cache responses. Responses must therefore,
implicitly or explicitly, define themselves as cacheable or not, to prevent clients reusing stale or
inappropriate data in response to further requests.
• Code-on-demand
• Extending client functionality
• Servers are able to temporarily extend or customize the functionality of a client by transferring
to it logic that it can execute. Examples of this may include compiled components such as Java
applets and client-side scripts such as JavaScript.
Features of Rest
• Simpler than SOAP
• Comes with a good documentation
• It has proper logging of error messages. E.g. lets say you are creating
a REST API using a particular framework , if you error it gives you the
error as it is.
Principles of REST API
• Stateless
• Client Server
• Uniform Interface
• Cacheable
• Layered System
• Code on Demand
Principles of REST API
• Stateless: When request are send from the client to the server. It contains all the
information that is required to make the server understand it. It can be URL, query string
parameters. URL uniquely identifies the resource
• Client Server: It has a uniform interface that separates the client from the server.
Separation of concerns basically helps it to improve users interface portability across
multiple platforms. It enhances the scalability of the server components.
• Uniform interface: REST has four interface constraints to achieve uniform interface.
Resource identification, resource manipulation, self descriptive messaging
• Cacheable: in order to provide a better performance the applications are mirrored as
cacheable. It is done by labelling the response from the server as cacheable or non
cacheable either implicitly or explicitly.
• Layered System: This allows the application to be more stable by limiting the component
behavior. It enables load balancing and provide shared cache for promoting scalability.
The layered architecture helps enhances application security as the components in each
layer cannot interact beyond the next immediate layer.
Methods of REST API
• We use the acrimony CRUD
• Create , Read, Update, Delete a resource.
• Resource is something the client want to know or the data the client is
looking for e.g. this URL https://mymovies.com/action/mukadota
represents a resource.
• To achieve CRUD you use the http methods which are methods of REST API
• C, Create we use POST
• R, Read, we use GET
• U, Update, we use PUT
• D, Delete, we use Delete
• POST, GET, PUT, DELETE are the http methods.
Monolithic Architecture
• Monolithic architecture is like a big container wherein all the
software components of an application are assembled together and
tightly packaged.
Monolithic architecture example
Drawbacks of monolithic application
• Large and complex applications: As the application gets complicated it

becomes difficult to bring change to the application(modifying the
application) as a result development slows down and modularity breaks
down. It can be difficult to correctly implement a change.
• Slow development: Its difficult for the team to understand and
collaborate. Updating the cart services results in redeploying the whole
application.
• Unscalable
• Unreliable: A bug in one service will distort everything since everything is
one process.
• Inflexible: Suppose you write an application using a certain framework.
Rewriting the application using another framework is very expensive(time
and cost). There is huge barrier adopting other technologies.
Microservice architecture
• Microservices/microservice architecture is an architectural style that
structures an application as a collection of small autonomous services
modelled around a business domain.
• Self contained process which avails different and unique business
capabilities. A large application can be broken into small multiple
services which together access one large system.
• In Microservice architecture, each service is self-contained and
implements a single Business capability.
• Multiple broken services that doesn’t share the same data structure
but they communicate through API. This increases quality.
Micro Services
Microservice architecture example
• In a monolithic architecture all services are in one module where as in
microservices are divided into multiple modules.
• The communication is a stateless communication. Each pair of
request and response is an independent transaction.
• Microservices communicates effortlessly.
• Each microservice is responsible for its data model.
• Each microservice is handled by different instances.
• We have three different services, customer, product and cart. Each
have their own instances, data model and their own data.
Microservice architecture
• The services are independent and loosely coupled.
• Each of the services has a separate code base. Can be managed by different small
teams and can be deployed independently.
• A team can update a service without rebuilding and redeployment of the entire
application.
• This services don’t need to share same technologies, same frameworks etc.
• Management component is responsible for placing services on nodes, identifying
nodes, rebalancing services across nodes.
• Service discovery: maintains a list of services and which nodes they are located. It
enables service lookup.
• API Gateway is the entry point for clients. Requests handled through the API
Gateway. This API Gateway might give an aggregated response from various
services.
Features of Microservice architecture
• Small focused: the aim of microservices is simplicity
• Loosely coupled: Each microservice is independent of each other , no
need for coordination.
• Language neutral: You can use multiple languages for multiple
services.
• Bounded context: Each service doesn’t need to understand the
implementation of other services.
Advantages of microservice architecture
• Independent deployment: Update a service without redeploying the
entire application.
• Independent development:single team can build, test and deploy a
service.
• Mixed development stack: Team picks any technology best for the
services.
• Fault isolation: If one service goes down, it doesn’t have to shut
down the entire application.
• Granular scaling: Services can be scared independently unlike
monolithic architecture.
Companies using micro services
Task 2
• Try to implement microservices using any framework of your choice
etc spring boot.
Web application vulnerabilities
• Injection: untrusted data is sent to an interpreter as part of command
or query
• Broken authentication: Incorrect implementation of application
functions related to authentication and session management
• Sensitive data exposure: Data at rest or transit not protected enough.
• Broken access control: improperly enforced restrictions on
non-authenticated/guest users.
• XML External entities(XXE):Poorly configured XML processor
evaluating external entity references within XML documents.
Web application vulnerabilities
• Security misconfiguration: Insecure default configurations of various
application functions or ad-hoc settings.
• Cross-site scripting(XSS): Inclusion of untrusted data in a new web
page without validation causing attackers to execute scripts in the
victim browser thus causing hijack user sessions, deface websites,
redirection of malicious websites.
• Insecure De-serialization: unmanaged or incorrect deserialization
leading to unauthorised RCE(remote code execution)
• Insufficient logging and monitoring: Not logging enough or not
monitoring the logs for timely incident response causes bigger attacks
to succeed over time.

Web Services and Security

Uploaded by

Copyright:

Available Formats

You might also like

Web Services and Security

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Services and Security

Uploaded by

Copyright:

Available Formats

Web Services and security

• Representational State Transfer (REST)

• Information is organized in the form of resources

• Large and complex applications: As the application gets complicated it

You might also like