In this lesson, we're going to discuss
the different web application components
that could be vulnerable to exploitation.
This includes client-Side Processing
versus Service-Side Processing,
JavaScript Object Notation
Representational State Transfer,
the Simple Object Access Protocol, Browser Extensions,
HTML5, Asynchronous JavaScript and XML,
Machine Code and Bytecode.
First, we have Client-side Processing
and Server-side Processing.
When your team is developing a web application,
one of the first decisions you need to make
is whether the code is going to be run
on the user's computer,
which is known as client-side processing,
or on the server, known as server-side processing.
Now as a web designer, we tend to prefer to code our things
for client-side processing
because it puts the load on the end user's machine
instead of on our server,
and this makes the program more responsive
and less costly for us to run,
but this is not always the most secure method.
Now this is a risk decision that has to be weighed
when you're designing a new web application
because server-side processing is considered
to be much more secure and trustworthy
than using client-side processing for most use cases.
In most modern web applications,
you're going to see the server
that hosts the functional logic and data,
and this can be accessed by your client's browser.
That browser is then going to manipulate
the final displaying of the data,
but all the actual code that's being executed
is happening back on the server.
For example, if you're accessing your bank account,
most of the code is going to be run on the server side.
Only the finished results are going to be sent
to the client's browser for display and processing
to be able to display it on your device.
Now on the other hand, if you're concerned
with having more speed and efficiency of code execution
and you don't care as much about security,
you may then use client-side processing
for executing that code.
For example, let's say, I'm making a web-based game
and the performance of the web app
is probably more important to me than the security.
In this case, I might shift
to a client-side processing model instead.
Just remember, whenever you use client-side processing,
the end user could modify the application's logic
using tools like Burp Suite or BeEF
to bypass security controls
and load malicious objects into the project.
Again, like I said earlier, this is a case
where you need to balance the risk versus the reward
when you choose client-side versus server-side processing.
Second, we have JSON REST,
which is the JavaScript Object Notation
Representational State Transfer.
Now the Representational State Transfer or REST
is a client server model
for interacting with content on remote systems over HTTP.
A RESTful web service chooses the format
that's going to be used during this HTTP exchange
and REST will support XML, JavaScript, and JSON formats.
By far though, the most commonly used format
for data transfer is the JSON format.
JSON is a simple text-based message format
that's used with RESTful web services.
JSON was developed for JavaScript
and is quite popular in most web applications.
Just like all data exchange interfaces,
JSON is subject to injection attacks,
just like an XML injection or an SQL injection.
To prevent an injection attack from occurring,
you should always code your JSON APIs
to inspect and sanitize all inputs and outputs
that are being provided to your applications code.
You're going to find that REST and JSON are preferred
over SOAP and XML
because less data is going to be passed over the network
and this makes it really good for mobile devices.
But if your web application needs more security
and transactional services,
then you may want to use SOAP and XML
instead of REST with JSON.
This brings us to our third topic, which is SOAP
or the Simple Object Access Protocol.
SOAP is going to be used for
exchanging structural information
for your different web services.
SOAP consists of a processing model, an extensibility model,
a binding framework, and a defined message structure.
SOAP passes more data and is more verbose than using REST
and its header passes it unencrypted.
For this reason, more and more developers
are migrating to REST instead of SOAP
because REST can be more secure
since it has an encrypted header.
Now you should be aware that SOAP APIs are often exploited
to perform SQL injections, content discovery,
authentication bypass, and other types of attack.
The number one method
to protect your SOAP APIs from exploitation
is to conduct inspection and sanitization
of your inputs and outputs for that application
just like you do for JSON REST applications.
Fourth, we have Browser Extensions.
Now browser extensions are small programs
that provide expanded functionality
or features to a web browser
that are not included in the default configuration.
Originally, all webpages were quite static and unchanging.
Over time though, programmers wide webpages
to become more interactive,
so they create other technologies including Adobe Flash
and Microsoft ActiveX as plugins
that added the desired interactivity.
Now Adobe Flash is an older plugin
that's reaches end of life
and is no longer supported by Adobe.
Still, there are some websites out there
that have not updated their code yet
and they still try to load up Flash to execute their sites.
This makes those websites and your client very vulnerable
because Flash has known vulnerabilities out there
and Adobe is no longer providing security patches for it.
For this reason, if you find Adobe Flash installed
on any of your network clients,
you should immediately remove it.
ActiveX is another plugin that used to be very popular,
but these days is considered deprecated and a legacy plugin.
ActiveX is a server-side technology
that uses object oriented programming,
the Component Object Model or COM,
and the Distributed Component Object Model or DCOM.
Now COM allows the software to communicate
while the DCOM allows the software
to be distributed across a large number of machines.
ActiveX controls, as the downloaded programs become called,
are installed into the operating system
and they run with system
or administrative level permissions.
For this reason, ActiveX has long been considered
an insecure technology
and one that should be avoided in your network at all costs.
In general, most modern web browsers
have moved away from plugins
and instead rely now on extensions.
Extensions are used to provide expanded support
and these extensions can be used
to alter how a web browser interprets and loads a webpage,
as well as provides additional interaction
with third-party services.
These extensions are essentially mini programs,
so you should be careful and only install extensions
from trusted vendors
to avoid putting your web browser at risk.
JavaScript is another technology
that was developed to add interactivity to webpages
because the original HTML standards
were not designed to support it.
Now JavaScript commands consisted of event handlers
and they're embedded directly
into the HTML code of a webpage.
JavaScript has also significantly expanded in recent years
and became essentially a full featured programming language
at this point.
Now fifth, we have HTML5.
HTML5 or the Hypertext Markup Language 5
is the latest version of HTML,
which is a markup language
and has added tremendous amounts of support
for things like multimedia
and effectively negates the need for Flash or ActiveX.
Most web developers have fully embraced HTML5 now
and web vulnerability scanners
have added the necessary signatures
to help discover security vulnerabilities insights
that are built with HTML5.
Now because HTML5 was designed
as a powerful web application programming language
that enables feature-rich applications,
it does have several areas
that can be exploited by an attacker.
These areas include things like the cross domain messaging,
cross-origin resource sharing,
WebSockets, server-sent events,
local offline and web storage, client-side databases,
geolocation requests, web workers, tab nabbing,
and sandbox frame as common areas that are exploited
in poorly coded HTML5 websites.
To avoid exploitation,
your developers should always follow
secure coding best practices
whenever they're developing any web application,
especially those using HTML5 or other programming languages.
Sixth, we have AJAX,
which is the Asynchronous JavaScript and XML technologies.
Now AJAX is a grouping of related technologies
that are used on the client side
to create asynchronous web applications.
AJAX has some built-in security features,
which are known as the same origin policy.
This requires that all that technology
comes from the same web domain
if they're going to be run on the same webpage.
The AJAX engine is an intermediary
that's going to load up when a user first requests a webpage
and allows user interaction
without constant communication with the web server,
and this reduces the amount
of required server-side processing.
By default, webpage are considered stateless,
which means they don't remember any user actions.
But this is not very useful for most web applications
because we need state management
to be able to know what a user is doing.
In the early days of the internet,
state management was conducted
by using cookies stored on a client's machine.
But due to security concerns,
much of state management is now done
through server side storage and databases.
AJAX is really useful in maintaining these sessions
and then conducting state management for us,
and it's considered to be much more secure
than other methods
because of the way the interactions
between the client and the server are going to be obscured
by using server-side processing of those scripts.
Now there are some common vulnerabilities
that are exploited in AJAX applications.
This includes cross-site scripting techniques
that target AJAX transmitted plain JavaScript user commands
that are going to the server
by identifying different function names,
database table names, user IDs,
and other sensitive program details,
and then they try to overwrite those
using malicious scripts.
Seventh, we have Machine Code
and Bytecode that we have to discuss.
Now machine code is the basic instructions
that are written in a machine language
that can be directly executed by the CPU or processor.
In general, when a developer writes a program
in source code,
it has to be compiled and converted down into machine code
that the computer can actually understand and then execute.
Now the problem with machine code
is that it is specific to a type of processor
that can only be run on that specific processor
for which it was compiled.
In general, most Windows machines run
on either an X86 based processor,
which is an older 32-bit type of processor,
or the newer X64 based processors,
which are 64-bit processors.
From 2007 to 2020,
Mac computers also used Intel based 64-bit processors,
but that was recently changed back in 2021
with the introduction of Apple silicon processors,
which are a form of ARM-based processors.
Similarly, mobile devices also use ARM-based processors,
and if the machine code was compelled
to be run on a Windows desktop, for example,
it will not run on an ARM-based processor.
Now to overcome this issue,
Oracle's Java programming language
uses the concept of byte code
to make its Java applets cross platform,
and so they can run on any system.
Bytecode is essentially an intermediate form of code
that's going to be produced by the compiler
that can then be executed by a virtual machine
that then translates the bytecode
into the final machine code for that processor.
This bytecode can then be interpreted
from the bytecode state
into the machine code on that system
using a Java virtual machine known as a JVM,
and that does the translation into machine code
that can then be run on the specific processor.
Now Java applets are another form of server-side component
that can then be downloaded from the server
and run in a Java virtual machine on the user's computer.
Java in the past has been known for having malicious applets
and many became wary of using Java because of its early days
when it was used for malicious software
that got run on machines.
But Java security has improved tremendously over the years,
including the introduction of the Java security model
making Java a great resource for programmers
who need to be able to create cross-platform applications
that can run on any operating system
because most operating systems
do have support for Java by default
using a Java virtual machine
to translate that bytecode into machine code
on any system or processor.