Welcome to a course on Application Security the course will highlight the features and characteristics
of both secure and insecure applications and examine the most widespread types of application layer
attacks.
To start off a secure application is an application that above all must be able to deal with atypical
unexpected or incorrect input.
Efficiently the most common types of attacks including buffer overflow as fuel injection or HMO cross-site
scripting rely on the insecure input handling of non-typical incorrect or specially crafted input.
How did this problem come about.
The picture above is an illustration of an obviously great construction achievement erecting the bridge
do not only require detailed planning but also putting the plans into action.
It requires the ability to predict all possible scenarios and circumstances and potential problems.
The result is an impressive bridge that feels and is safe.
What it means for us is that creating safe solutions is possible regardless of scale.
Unfortunately though constructing a faultless bridge even as large as the one in the picture is less
demanding than writing a secure application.
It's easy to foresee the external threats a bridge will come up against in its use.
It's wind and water the factors can be provided for during design and the completed design will only
need to be followed exactly applications on the other hand have to be immune against unforseen factors
and threats against unexpected exploitation attempts launched by knowledgeable attackers.
The scale of the problem is altogether different.
We could write an application that doesn't act up if all allowed input would be in the specified range
or would be valid creating an application that is secure.
Per se is far less easy
a secure applications default settings should be at once the safest options.
The rationale for this is that the majority of users don't change the configuration after they've installed
an application
especially features that aren't used on a daily basis will rarely be disabled.
If the features aren't being used or worked with this usually means that a user is not aware of them
disabling features that you don't know exist is rather tricky
if an applications default configuration is the most functional.
You face the risk that it would run in a much wider range than the tasks it's usually made to in the
range you can't see is the range you can't protect
a secure application is an application that doesn't need escalated or superfluous permissions to run
administrative permissions in particular should not be required
these rules are the principle of least privilege and the principle of minimising attack surface areas.
They both work to reduce fallout from a potential attack.
If an application runs under a standard user's permissions all changes that can be made will only apply
to the user's session.
The next step will be to adopt a model that is popular in the line X in Unix environments.
Escalated permissions are not necessary.
There are not only to run an application but also to install it an application would be installed per
user and the user would be held responsible for it.
Carnegie-Mellon research shows that for every 10000 lines of code there are from 15 to 30 programming
bugs about 5 percent of the bugs are security critical affecting the security of the application or
indirectly the security of the system in users.
This means that if a program contains 10 million lines of code it will have 20000 bugs on average a
thousand of them may have a bearing on the application security.
That's quite a large number.
If we were able to create a truly secure application it would have to be flawless as you can see though
this is nearly impossible.
If an attacker spots and exploits just one of the thousand vulnerabilities they'll take over the application.
Of course this depends on the permissions that it runs under and how critical the bug was.
Application Security is especially vital in view of the fact that in 2005 the number of detected system
holes the bugs that are security critical dropped lower than 10 percent of all identified vulnerabilities.
This means that application bugs account for 90 percent of all vulnerabilities administrators and users
possibly out of habit usually spend most of their time on protecting operating systems.
It can be said that 90 percent of an administrator's working hours are spent on eliminating threats
that are less than 10 percent of all applicable hazards.
What makes things even worse is the application layer attacks succeed regardless of any security solutions
implemented in the system or network layers.
Detects don't modify network packages in ways that are not provided for by protocols they don't scan
any ports.
That's why firewalls and intrusion detection systems are easy to bypass
an application attack is indistinguishable from normal usage for a computer network.
Apart from that an application is run directly by a user and since as a user who's run it a system can't
disable it from performing any operations.
It was the users informed decision to run the program.
The system will not control it.
From then on we're ignoring the solutions that are less popular today.
Like permissions that are granted to code or application and not to user in a context of a user session
and application is free to do anything.
Well try to answer some interesting questions in this module.
What's the typical schema for a buffer overflow attack.
Why is modifying or controlling program execution possible without modifying the program's source code.
Why our database is vulnerable to ESC fuel injection as CULE query manipulation attacks.
Can these database servers and database application attacks be automated.
Why does a cross-site scripting attack target the pages visitors and not the web page itself.
How can an attacker impersonate an authenticated user of a web application.
Finally we'll try to see if there's some way to prevent users from running insecure or harmful programs.
We'll also discuss the features and characteristics of insecure programs.
See you in the training.