All
right, let's go ahead and take a look at
Module 9, which deals specifically with application security.
All right, so definition, what is a secure application?
An application is secure if it's ensuring
confidentiality, integrity, and availability of its restricted resources.
Restricted resource defined any object, data, feature, or function of
an application designed to be accessed only by authorized users.
We're back to that whole authentication, authorization, discussion.
Once you've been identified
and you've authenticated or proved it, then what are you authorized to access?
That level of access should be, again,
everybody all together now, based on the principle of least privilege.
How do you however?
Quite often, your privileges or permissions are not granular enough.
There's excessive permissions or
privileges that are provided by database connectivity or web application tiers and
so forth that give you unexpected elevated privilege.
Not a developer by background, have
nothing but respect for developers, don't get me wrong, but developers really are
tasked with some opposing objectives these days.
They've got to develop a software application.
The whole purpose for that is cool
functionality and ease of use, reliable, performs well.
Then you get that opposing objective now
is security, which didn't used to be their responsibility.
You ask any old school programmer, how much of your training schooling dealt
with security, and then little to none, that's not my deal.
We would secure the application and the infrastructure after the fact.
We really have no choice these days but to bake security into the software
development lifecycle, which is now maybe tying one arm behind the back of the
developer, forcing them to secure the application and the development process.
There's quite often weaknesses or vulnerabilities in the
application that can be exploited to give you excessive privilege.
In the mind of the developer, they're ensuring functionality, elevated
privileges to a database connection for an application that merely verifies whether
or not your username and password combination is correct.
What could be the harm in that?
Well, the harm is when somebody actually injects an additional query into a SQL
query and hijacks that database connectivity with system level privilege
and executes extended procedure command shell functions.
So a secure application is
properly going to authenticate and authorize principal lease privilegeand
provide no ways around workarounds or vulnerabilities that can be exploited.
So there's lots of possibilities on that.
The need for application security.
A common myth, perimeter security controls can secure your application.
These controls are not effective to defend
application layer attacks because Port 80 and 443 being open allow for
legitimate web traffic, attackers can use normal application web traffic
to exploit application level vulnerabilities and get into the network.
So if we have the ability to talk to
something, we have the ability to potentially attack it.
If we're not validating or sanitizing that
user's supplied input, we're in real danger.
So we'll talk more about that.
But all of your data should be sanitized and validated and verified.
We could stop a lot of the stuff down in this stuff dead in its tracks.
We're going to talk about different ways to do that.
Our application security administration
involves actions of managing and administration the security of the
applications installed on our organization's computer networks.
Security administration responsibilities, protecting users from downloading and
installing potentially harmful applications, preventing applications from
creating and modifying execut files, accessing, creating, modifying operating
system resources, preventing applications from spying various processes, etc.
Your best practices for achieving some of
these goals are application whitelisting or blacklisting, which we're going to talk
about, application sandboxing, application patch management,
and the use of web application firewalls or application level firewall deployments.
And you'll be performing labs in each of these areas.
The three W's in application security.
Why should we care about application security?
Because without it, your application is
going to be exploited until the cows come home.
You're going to have tons of security
breaches, loss of market share, reputation, loss of revenue, etc.
What do we need for application security?
Constant vigilance required at various phases of the development lifecycle.
We need to bake it in rather than bolt it on after the fact.
If it's baked into the development process,
you have a much more secure, resilient application.
Then who?
Who's responsible for application security?
Managers, architects, developers, testers, and administrators responsible for
application security, and to a degree users because they provide feedback.
Devops, for example, is development and
operations working together to develop software, where historically, development
developed the software, operations used it, and you can have a bit of a disconnect
there between the vision, the product, and then the final result.
All right, secure application design and architecture.
Negligence at design and architecture may
lead to vulnerabilities that are difficult to detect and expensive to fix in
production, recoding, patching, or using alternative controls.
Vigilance at each phase enables detecting
security flaws early in the process so they can be remediated.
Security design of an application is based on security requirements identified in the
previous phase of the software development life cycle.
Now, we've touched on a couple of maturity models.
I talked a little bit about software development capability maturity model.
We're also going to be looking at a secure software design life cycle, which is a
bunch of different frameworks and different techniques.
You have Agile, Scrum, you got Waterfall, Spiral Methods, and a bunch of others.
Our secure design is a challenging process.
Designing required security controls may
obstruct the business functionality requirements.
Remember, functionality and security often go head to head, opposing objectives.
Remember, we're in business to be in
business not to be secure, but we want to be reasonably secure and
reduce our list to an acceptable level, which again is dictated by management.
The goal of the secure design process, identifying threats for developers to
understand and code accordingly to mitigate the risk associated with the
threats, designing the architecture in such a way that it mitigates as many
threats as possible, and enfor secure design principles that
force developers to consider security while coding.
A lot of this is going to be process, right?
Development process, and again, that capability maturity model
illustrates exactly how advanced you are in that phase, whether you're doing things
the same way over time based on best practices, quantitative data, and if
you've built in a mechanism for process refinement.
All right, secure design actions.
Specify your requirement specifications.
Design the application according to the
security specsgathered at the requirement phase.
Threat modeling.
Perform threat modeling to know your threats.
Implement secure design principles.
Define the secure coding standards to be implemented in the development phase.
Secure application architecture.
Design and secure application architecture.
I probably actually went a little out of
order here, but design a secure application architecture.
Security requirement specifications.
You need to figure out, first off, what
it's going to do, what we need to accomplish, what are the security
requirements, authentication requirements, and so forth.
Software security requirements are nonfunctional requirements
which need to be addressed to maintain the CIA of the application.
Stakeholders often overlooked security
requirement during the inception phase of software development.
You just get to the coding, and again, you
haven't really planned for what you needed to do.
Negligence may result in the application
being vulnerable to different types of attacks or getting abused.
Gathering security requirements should be
part of the strategic application development process.
Defining learning secure design principles.
Secure design principles are the state of practices or guidelines that should be
enforced on the developers to follow during the development phase.
Deriving secure architectural decisions helps to eliminate design and architecture
flaws, mitigate common security vulnerabilities within the application.
Again, this is academic for me.
I'm not a developer.
I'm generally not involved in the software development process.
This is at the academic level.
I don't have a lot of experience for you on this one.
Threat modeling.
Threat modeling process of identifying, analyzing and mitigating threats.
In a nutshell, you analyze the application.
You figure out, Hey, how can I talk to it?
Once I talked to it, where does that talk go?
What does it traverse?
What components internally and externally?
Is it handed off to other servers?
Where can I attack it?
Where is it unprotected?
Where can I submit unexpected input?
And a ton more?
Structured approach to rate threats based on the architecture.
It's performed at the design phase of the security development lifecycle.
It's also done after the fact.
Iterative process that starts the design and iterates throughout the application
lifecycle until all possible threats to the application are identified.
All possible threats, and ultimately exposes all possible
threats and vulnerabilities on an application.
There's always going to be an unknown somewhere.
We do our best to figure it out, all known vulnerabilities.
The process,
really quickly without getting into too much detail of each step,
identify security objectives, application overview, decompose the
application, which is just analyze it, identify threats,
identify vulnerabilities, risk and impact analysis, and then potential remediation.
A typical web application architecture comprised of three tiers.
You have the web server, the application, and the database.
Security at one tier is not enough as the attacker can breach the security of
another tier to compromise the application.
Design web application architecture with
defense in depth principle, providing security at each tier of the web
application, a multi tiered solution includes proper input validation, database
layer abstraction, server configuration, proxies, web out firewalls, and so forth.
So again, you have multiple points of connectivity.
Connect to the web server, input validation, that gets passed back to the
web application, which gets queries passed back to database servers, etc.
So illustrated, tier 1 is the web server, tier 2 is the
application server, tier 3 is the database server.
I'm going to show you an example here
of a SQL injection that runs here and helps us to visualize all this.
This is one of the demos I'll do in a CH or CHFI class.
We'll go ahead and take a look at it here as
well. All right, so I'm going to bring up a very straightforward, very simple
banking application on an unpatched Windows 2000 box.
All right, so this has nothing to do with the unpatched Windows 2000 box.
This is actually my first victim machine I
ever built for CH version 3 when I first started teaching the course.
It's got such a nostalgic value,
sentimental value to me that I still keep it around on my test labs for fun.
It's got lots of vulnerabilities to take a look at.
So no cracks about the Windows 2000 box.
The application is extremely simply coded, and it's really
great for demonstrating vulnerabilities because it is so simple and
straightforward even for the non developer types.
So example, I'm going to open up Coastal Bank,
which is an online banking SQL injection demonstration page.
Okay, on the server side, we're going to take a look at the code.
All right, so this is the client2htm page,
which I've got open on my ESX Windows 10 box.
Then I've got a login. Asp page.
I'm going to open that with Notepad.
Then I've got a SQL Server database
that maintains the tables and the database for the web application.
All right, so this is an anatomy of how web application might work.
Okay.
On my client side, I'm going to try to log in with the
username of Eric and a password to password.
I get access to his Denied.
That's a programmatic response because I
didn't submit a correct username password combination.
On the server side, those are my two valid
usernames and passwords, Bob and Alice with passwords of password.
Notice Eric is not in the list, thus denied.
If I was to log in with Bob and a password of password, I'm in.
I've logged in successfully because Bob and password credentials match.
So very simple logic.
The active server page login ASP
takes the input from the client.
If I view the page source, we can actually see, and again, this is
why I use an older application here, way simpler than a newer web application.
But I've got a post action to login.
Asp, where I'm going to input a type of
text, call it username, input a type of password, call it password.
Those are going to be passed to login ASP.
Here's my submitted user input.
On the receiving side, it's going to run a
select statement from the user info table with the submitted username and password.
So what I type in gets copied into this
query or injected into if you want to look at it that way.
The SQL Server then matches the username and password.
If it's correct, we get ebanking. Asp.
If it's not, we get bad log on.
All right, pretty straightforward.
Not a lot of danger here, right?
Because after all, if they don't have the
right username and password, we're just not going to log them in.
But here's where the issues start.
The privileges on this application are excessive.
So you've got a user ID of SA, SQL Admin,
get a blank password, which that's not good.
That is system level access for this particular installation of SQL Server.
So those privileges don't get any higher, system level privilege.
But all we're really doing is determining if their credentials are correct.
So what could be the harm?
Well, the harm is when somebody can inject into that statement and hijack the SQL
query, and now they've got system level privilege.
That's not good.
So I'm going to show you one example, maybe a couple.
The first thing I do as an attacker is I try to break something.
So I'm going to do a single quote and I get an odbc error
telling me I've got an unclosed quotation mark before character string and password
equals yada yada yada and SQL login ASP line 5.
That's an example of error message verbosity.
And that's also an example of why you want to suppress verbose error messages because
now I know it's a Microsoft SQL Server and I know to use Microsoft SQL Server syntax.
Next, I'm going to try an input validation or authentication bypass.
I'll do a single quote or 1 equals 1 tack tack.
1a equals A would work as well.
Let me try that again.
Or 1 equals 1 tac tac.
Now I'm in.
Well, what?
Yeah, if you look at the logic,
we're using the am equals quote or 1 equals 1 tack tack, basically you're
saying if whatever I type in for the username matches or if 1 equals 1, which
is a condition that's always true, log me in.
The tac tac comments out the remainder of the query.
I just completely hijacked that query and
I've hard coded it to be a successful response and logged into ebanking.
You'd be amazed at how many sites are
vulnerable to a simple input validation attack.
It gets worse.
I'll show you one more example here.
This is the full list I'll typically do in
a CH class, but there's this Master XP Command Shell.
Master Extended Procedure, Command Shell,
and that gives you command shell functionality.
So for example, I could add a user
account, I could insert into the database different values, etc.
I could deface the website.
Let's do that because that's a lot of fun.
All right, so if I take a look,
this is the original site.
There is my development savvy in action.
I coded that myself.
If I go back and this time do a single quote,
semi colon execute extended procedure echo your hacked into default.
Htm just to face the web page.
I'll hit submit.
Access is denied, which just means I wasn't validated.
When I hit refresh, looky there, you are hacked.
It gets worse than that.
But that gives me the ability to hijack
those SQL queries with elevated privileges on the database management system.
I can also access the system level account local operating system.
I can do a bunch of stuff with that.
But we'll rate it back in.
You have to come back for CH if you
haven't already for the full discussion on SQL injection.
Those are a couple of things you can do with injection.
Now, what could have fixed that?
Disabling the functionality to begin with,
vetting the user's supply to input, making sure it's actually in the expected format,
never building queries and statements directly from user's supply to input, etc.
But that's a little bit longer discussion.
We could have filtered it at the early
stages of the application, middleware components, or even the database.
All right, so input validation.
Whenever you get a question on a security
exam that says, Hey, what can you do to prevent web application attacks?
Always look for input validation as an
answer choice because it fixes a lot of those stuff.
Input validation can occur on the client side or the server side.
If it's client side, you can actually tamper with the input after
it leaves the browser using a proxy, for example, or you can strip the script
that's enfor the type safety out of the page.
On the server side, you're increasing processing load if you're
actually checking on this on the server side.
A lot of times it's just checked at the client side.
All right, so allowed character set, minimum maximum length, check the input.
Is it in the allowable format?
All right, parameterized queries.
In parameterized queries, the SQL query is written without embedding parameters.
Each parameter query is supplied dynamically later helps the distinguishing
between code and data, irrespective of user input.
So one of your standard responses to
protect against SQL injection, parameterized queries.
You can parameterize stored procedures.
Stored procedures in general are
functionalities above and beyond normal database functionality.
Things like adding user accounts, running
make web tasks, extended procedures command shell, anything that's
not typically part of the querying, reading, updating, and deleting process.
Secure coding practices.
Okay, normalization.
Normalization puts things in a standardized format.
Unicode normalization is the process of
normalizing strings and determining whether two given Unicode strings are
equivalent based on the chosen normalization form.
One pretty standard way to evade detection is to use alternative coding.
Unicode coding is pretty common in things like directed traversal
attacks or various types of obfuscation attacks.
In normalization, it should be mandatory
because in Unicode, a character string can have many alternative representations.
Web application that accept unknown input strings use input filters and validation
processes depending on the types of characters.
When you're trying to sneak past the
security gate or the gatekeeper, you're putting your code in alternate but still
functional format so that doesn't match the signature.
We looked at our IDS Signatures and we
looked at, for example, case sensitivity orientation.
Anything that doesn't match the signature
that still preserves the functionality may be successful.
Output and coding.
Ensuring that data that is output is converted to special characters in a
different format so they're no longer vulnerable at the target interpreter.
A great example for...
I'll show you a cross site scripting attack here real quick.
Let's do that.
Without getting too into CH mode,
I'm going to log in username is Sam and test.
Hey, there's the cross site scripting from my last demonstration.
I must not have reset this server since my last CH class.
When I go and I leave a message and I tag it as a script
and close the script, instead of data to be split on the screen,
the browser interprets it as a script to execute.
Submit.
And there's my new Eric Cross site scripting.
So I would neutralize that or sanitize
that by using HTML Encoding, < for less than sign, > for greater than sign.
And the idea there is it converts it to a non executable character but still allows
it to display angle brackets on a response page.
So output and coding is one mechanism for preventing attacks like cross site
scripting, allows unsafe characters and renders them as harmless text.
Error and exception handling.
You want to suppress verbose error messages.
We saw an example of that with my O DBC error.
Exceptions, the unusual errors that arise
during the execution of a program or an application.
Exception handling anticipates, detects
and resolves programming errors during the execution of an application.
But when you get feedback from an error or exception, then that gives you
some insight into the structure of the application.
That stuff should be suppressed after the application goes into production.
During development, absolutely, because
you're trying to work out the kinks, but once it's done and ready to roll out,
you're supposed to, best practice, suppress error messages.
All right, session cookies.
Browsers use cookies to maintain a session state, which is typically a unique
identifier allocated to the user after they have logged in and authenticated.
So I can steal your session identifier if
I can steal your cookie and I can replay that from a remote system and then
potentially make the system believe I'm you.
So again, come back to CH for a full demonstration of that.
But session hijacking is stealing a user's
session token and then typically replaying it from another location.
So a couple of considerations.
Don't store plain text or weekly encrypted passwords and cookies.
Encrypt your sessions SSL, TLS, issue random session IDs.
Our response headers.
A secure response header enhances
the security of a page in the global network, hardens the application against
security threats, and prevents browsers from delivering vulnerable resources.
So HTTP, Strict Transport Security or HSTS, Content Security Policy, and Cache
Control all deal with security response headers.
And again, not a developer, so I don't do a lot of the actual hardening.
I tack them quite a bit.
But HSTS forces browsers to interact using HDPS that
prevents things like SSL stripping and tax from taking place.
Content Security Policy protects browsers
from cross site stripping, code injection, click jacking, other types of attacks.
And cash control operates based on the
directives of the rules for implementing cash request responses.
Cash poisoning in general is where you put a malicious cash entry in a target system,
and instead of using a live request or resolution, it uses the cash entry.
Obfuscation or camouflage, a technique used by application developers to secure
their codefrom reverse engineering by attackers.
Modifying the application executable so you have to guard the code from illicit
access, data tampering, license cracking, and intellectual property theft.
So it's hardening the application against
reverse engineering, dis assemblers, and that thing.
Code signing. We've talked about Signature's code
signing signs the code from the developer, and the idea there is you
can verify its authenticity as long as you trust the certifying authority that's
issued the software development certificate.
Code signing, digitally signed software, product updates or executables.
It's used to verify the integrity or authenticity of an application.