Time
56 minutes
Difficulty
Beginner
CEU/CPE
3

Video Description

Applications, Security Controls and Techniques Welcome to Chapter for on Application Security Controls and Techniques. In this lesson we explore and explain several key terms and how they help you determine they types of security controls concepts you deploy and when. For example, we'll introduce you to Fuzzing, error exception handling and input validation and explain what you learn from the results of those testing tools. You'll observe a demonstration of Cross Site Scripting, the relations ship between the programmer & end user, and learn how it goes about redirecting otherwise reliable resources on the network or website. [toggle_content title="Transcript"] This deals with explaining the importance of application security controls and techniques. Application security controls and techniques the first item we'll look at is Fuzzing. Fuzzing is the practice of testing your servers to see how they respond to errors. You want to use a fuzzing tool you throw – it is the practice of throwing random information at your servers to see how your servers respond. So that maybe the error messages that are given out by the systems, or the behavior of the application, or the server operating system you could then ask your programmers to fix or suppress the messages that are given out. Malicious persons could use the error messages to deduce what needs to be done. So by fuzzing, you are throwing random information at the server. You throw scripts, you throw codes, you throw some data at the system to see how it responds. That way you can better protect yourselves against attacks like SQL injections attacks, you can protect yourself against buffer overflows and XML attacks. Because this way you already know how the system responds and your programmers and system architectural persons can better respond to these error messages or the behavior of the servers to prevent malicious persons gaining further knowledge as to how to exploit these flaws should they exist on your systems. We should also follow secure coding concept. These involve error exception handling and input validation. When we follow secure coding concept we ensure that security is built into the code from the beginning. Security considerations are given to the applications while they are being designed by the programmers. We don't want to put security at the end; this way, it will be very obvious, it will be very easy to compromise or bypass. If security is built into the application from the start, it becomes transparent to anybody trying to use it. We should employ error exception handling. You want to suppress certain error messages. You don't need the system disclosing the full message, even if access was not granted. Say for example a malicious person is trying to gain access to your server, they key in the ID and also they key in the password. Should it be the ID is correct, you don't want the system to telling them your password is wrong. Rather you want the system saying either your password or user ID is wrong. That way the malicious person still does not know what end is wrong. But where the error message reveals one item as wrong only, that way we already now know that a part of a guessed (or guest) ID is correct. So this allows the malicious person to further focus on information that is unknown. But if we practice error exception handling, we are able to suppress certain errors. In some systems, even if the attempt is unsuccessful, maybe the system will be programmed to show nothing. Just show a blank page, but you don't want a system that would reveal the error to the user or the malicious person whereby they can take further action to compromise the system. So this is what we do if we follow error exception handling. We also need to do input validation. We need to ensure that we understand what can be keyed into every field. Malicious persons would like to inject code within these fields so that they could carry out malicious activities on the servers. If our programmers insure input validation everything keyed into the fields would be properly validated to see that they meet the requirements of the organization that is putting this server on the Internet. So, once the requirements are met, it will mean that no codes, no scripts, no commands can be keyed into these fields. And even if they are keyed into these fields before the system executes them on the server; before it pushes this information to the server, the entries will be validated to see that unnecessary scripts are thrown out. That way we nullify the code that is being pushed to the server. Cross site scripting prevention is another method with which we could mitigate the attempts of malicious persons trying to attack our servers. A cross site scripting attack is carried out by the attacker injecting code into the pages of unsuspecting victims. So the cross site scripting attack can provide a platform for further attack, such as phishing or browser exploit, redirection and misdirection are major components of this attacks. They can be used on active web sessions as well and they can be used to snoop on private postings. Methods to prevent these attacks - the cross site scripting attacks, occur on two sides, that of the programmer and that of the end user. So the end users can implement security controls on their work stations to ensure that maybe they can detect and prevent cross site scripting attacks such as running anti-malware solutions on their systems, or anti-spyware solutions on their systems. These systems would have this anti-malware anti-spyware and they ensure that they regularly update the signatures so that they can detect intrusions onto their systems. Programmers also play a larger picture in cross site scripting attacks. They can validate input and address vulnerabilities by releasing security patches in a timely manner. Cross site request forgery prevention could be carried out. Cross site request forgery attacks can be very difficult but our end users can install add-ons for their web browser, empty their temporary files. Their temporary internet files could be emptied periodically, they need to keep their browsers patched up to date. The browsers be it Internet Explorer, Mozilla Firefox, Google Chrome or any other browsers that are out there. These are applications that get updates. Our end users should ensure that they have all these updates in a timely fashion and they run these updates on their browsers to ensure that there are no flaws present within these applications. Our administrators can also prevent cross site scripting attacks, request forgery attacks by following best practices by deploying web application firewalls. These web application firewalls will filter traffic that is being pushed at the servers to enable them scan the headers of the packets moving on the network. Application configuration baseline. These are application proper settings. The administrators on our networks should ensure that applications are properly set so that malicious persons could not use these applications in ways they are not meant to be used. By locking down applications to meet the specific roles of the users on the network, it is possible that the portions of the applications that could be used maliciously are not made available. This way, we are able to keep the applications to a specific baseline. Application patch management. Our software, our applications we use, they are not perfect. Our administrators should periodically scan the Internet to seek the patches that are released, as they are released by the manufacturers. These patches have to be validated. We need to authenticate that yes these patches have been released by the vendors. Then the patches should be tested in a test environment to see is it robust? Does it do what they say it does? Once these patches have been properly tested, we then migrate them to our systems and apply them appropriately so that our systems are best kept up to date. By doing proper patch management we can validate, and we have the assurance that our systems are working as we desire. Careful testing has to be done for the patches. You don't just download the patches from the Internet and install on our computers. Malicious persons might also craft their malicious payloads to look like patches. So you want to validate the source of the patch. You want to test the patch on your test servers, then migrate it to your production environment. This should be done by the administrators; the testing and the validation. You don't leave testing to your end user. They don't know what to look for. They might be careless with their testing procedures. So our systems administrators should take care of application patch management. Server-side verses client-side validation. There are some entries we could leave for the server-side to validate. There are also some entries we allow, or prefer validation on the client-side because it is much faster. The client can easily detect that there is an error and quickly correct it rather than we wait for the error be detected by the server. That puts too much load on the network or on the network servers. So some input if improperly done could be validated at the client-side. That way the client who is there sees 'oh, I made a mistake' or that was a typo they can quickly fix it. So, some inputs are better validated on the client-side than relying on the server-side. However, the server-side should also be configured that, could it be that the mistake is omitted or is not detected by the client, the server can also detect these mistakes and validate the input. [/toggle_content]

Video Transcription

00:04
these deals with explaining the importance of application security controls on techniques,
00:10
application, security controls and techniques. The first item we look at is forcing.
00:15
Forcing is the practice off testing your servers
00:20
to see how they respond?
00:23
Toe errors.
00:24
You want to use the forcing tool you true, It is the practice of training random information at your service to see how yourself as respond
00:33
so that
00:34
maybe the arrow messages that are given out by the systems or
00:39
the behavior off the application or the server operating system. You couldn't ask your programmers toe fix or suppress the messages that are given out. Malicious persons could use the error messages
00:55
to deduce
00:57
what needs to be done,
00:59
so bye.
01:00
Forcing
01:03
you are truly random information on December you troop scripts, you true codes you true some data at the system to see how it response. That way, you can better protect yourselves against attacks like SQL injection attacks. You can protect against both overflows
01:21
on XML attacks
01:23
because this way you already know how the system response on your programmers on systems architectural persons can better respond to these Aargh messages or the behavior. All the servers toe prevent malicious persons gaining for the knowledge as to how to exploit.
01:42
These floors should exist on your systems.
01:47
We should also follow secure code in concept
01:51
on these involved. Aargh Exception Handling on input validation.
01:56
When we follow secure coding concepts, we ensure that security is built in tow. Um, the court From the beginning,
02:05
security considerations are given to the applications while they're being designed by the programmers. We don't want to put security as the at the end
02:13
this way. It would be very obvious it would be very easy to compromise or bypass. If security is built into the application from start, it becomes transparent to anybody trying to use it.
02:24
We should follow. We should employ.
02:29
See Kyoko Aargh! Exception handling.
02:31
You want to suppress certain Aargh messages?
02:35
You don't need the system Disclosing the full message. Even Eve at access was not granted.
02:44
Say, for example, a malicious person is trying to get access to yourself,
02:49
the key in the i. D. And they also came in the password.
02:53
She'll be The idea is correct. You don't want the system telling them your password is wrong. Rather, you want. This is what I'm saying Is that your password or user? I d is wrong that way. The militias person still does not know
03:07
what end is wrong, but where you just stay. Where did error message reveals
03:15
one item as wrong? Only
03:17
that way we already know. No,
03:20
that a part off
03:23
guest i d is correct.
03:25
So this allows the malicious persons to for their focus on information that is unknown. But if we follow
03:34
if we practice Aargh exception handling were able to suppress certain errors in some systems. Even if the system is the attempt is not successful. Maybe the system should be programmed to show nothing.
03:47
Joshua Blank page.
03:50
But you don't want a system that would reveal
03:53
the error to the user or the malicious person whereby they can take for the action toe compromise the system. So this is what we do. If we follow a rare exception handling, we also need to do input validation.
04:08
We need to ensure that we understand what can be keyed into every field.
04:14
Malicious persons would like to inject court
04:15
within these fields so that they could carry out malicious activities on the service.
04:21
If our programmers ensure input, validation, everything keyed into the fields would be properly validated to see that the meet the requirements off the organization that is putting the server on the Internet. So once the requirements are met, it will make that it will mean that no
04:42
codes, no scripts, no commands can be keyed into these fields on, even if they are keyed into this fields before the system executes them on the server before it pushes disinformation to the server, the
04:56
entries will be validated
04:59
to see that on necessary scripts. Troon out that way. We know if I record that is
05:06
being pushed to the server
05:11
cross site. Scripting prevention is another method with which we could mitigate the attempt off malicious persons trying to attack our servers.
05:20
The cross eyed
05:23
scripting attack is carried out by the attacker injecting code into the pages off unsuspecting victims, so the cross site scripting attack can provide a platform for for the attack
05:33
on DDE,
05:34
such as fishing or browser exploit, redirection and misdirection. Major component off these attacks. They can be used on active Web sessions as well.
05:46
On dhe, they can be used to snoop on private postings,
05:49
metals to prevent these attacks because I scripting attacks can choke on two sides that that off the programmer and that of the end user.
05:59
So the end users can implement security controls on their workstations to ensure that maybe they can detect and prevent cross site scripting attacks such as running anti malware solutions on their system or antispyware solutions on their systems. These systems would have this anti malware antispyware
06:16
on the ensure that they regularly orbit
06:18
the signatures so that they can detect intrusions onto their systems. Programmers also play a larger picture in cross eyed Cross that script in attacks.
06:30
They can validate input
06:31
on address vulnerabilities by releasing security patches in a timely manner.
06:38
Cross that request. Forgery prevention could be carried out.
06:43
But could the cross that request Forgery attacks
06:46
can be very difficult, but our engines as can install a Don's
06:50
for their Web browser, empty their temporary files. They're temporary. Internet files will be empty. Periodically. They need to keep their browsers patched up to date,
07:00
the browsers beat Internet Explorer, Mozilla Firefox, Google, Chrome or any other brothers that are all there. These are applications that get updates. Our Indians, I should ensure that they have all these updates in a timely fashion. Andi around these updates on their browsers to ensure that there are no floors
07:19
present within these applications.
07:21
Our administrators can also prevent cross I'm treating attacks, request forgery attacks by following best practices by deploying Web application firewalls. These were publication Firewalls will feel the traffic that is being pushed at the service
07:38
to enable
07:39
them scanned the header
07:41
head us off the pockets. Moving on the network
07:45
application configuration Bears line is our application proper settings.
07:49
The administrator's on our networks. You will ensure that applications are properly set so that malicious persons could not
07:57
used this applications in ways they are not meant to be used by locking down applications to meet the specific rules off the users on the network, it is possible that the
08:09
portions of applications that will be used maliciously are not made available.
08:15
This way we are able to keep the applications to a specific baseline application patch management.
08:22
Our software applications we use, they're not perfect.
08:26
Our administrators should periodically scanning Internet to seek
08:31
the patches that I released as they are released by the manufacturers. These patches have to be
08:39
validated. We need to authenticate that. Yes, this patch patches have been released by the vendors. Then the patches should be tested in a test environment to see. Is it robust?
08:50
Does he do what they say? Does one of these patches have been properly tested? We then migrate them, tow our systems on apply them appropriately so that our systems are best kept up to date.
09:01
By doing proper patch management, we can validate on. We have the assurance that our systems are working as we desire.
09:09
Careful testing has to be done for the patches. You don't just download the patch is from the Internet and install on your computer's malicious persons might also craft their militias payloads
09:20
to look like patches. So you want to validate the source off the patch? You want to test the patch on your test servers, then migrated to your production environment?
09:31
These should be done by the administrators. They testing on the validation. You don't leave testing to your end users. They don't know what to look for.
09:41
They might be
09:43
careless with their testing procedures, so our systems administrators should take care off. Application patch management
09:50
sub aside buses, client side validation.
09:54
There are some entries we could leave for the server side to validate.
09:58
There are also some entries we allow
10:03
or prefer validation on the end. Use declined side because it is much faster. Declined can easily detect that there is an error on the quickly corrected rather than we wait for the era be detected by the server. That puts too much load
10:18
on the network on the network service. So some input, if improperly, don't who will be validated at declined site.
10:28
That we did splint is there seems that Oh, I made a mistake or
10:33
that was a typo. They can quickly fix it.
10:35
So some
10:37
inputs are better validated on the client side than relying on the server side. However, the server side should also be configured. That would be that the mistake is meted or is not detected by the client. The server can also detect this
10:56
mistakes on valley date.
11:00
The import

Up Next

Fundamental System Security

Commonly referred to as INFOSEC, refers to the processes and methodologies required to keep information confidential.

Instructed By

Instructor Profile Image
John Oyeleke
Lead IT Security Instructor
Instructor