Introduction to IT and Cybersecurity
Time
1 hour 41 minutes
Difficulty
Beginner
CEU/CPE
2
Video Description
Information Leakage is a type of security flaw that can allow malicious user s to reveal confidential information from within an application. In this AppSec Tutorial, developers will see how Information Leakage flaws manifest and then learn to defend their code against this threat.
Video Transcription
00:06
opsec tutorials,
00:08
information leakage
00:10
about this course.
00:13
Information leakage is a type of security vulnerability that can affect nearly any application.
00:18
Any time a system discloses sensitive information, it could potentially benefit malicious users who depend on such information to succeed in their goals.
00:27
In this course, you'll see some examples of how this weakness can arise and how it can be addressed
00:33
to get the most out of this course. If you haven't already done so, we recommend that you take our introduction to Web applications Security Course first.
00:42
Hello,
00:43
My name is Kevin Richard, and I'm a security researcher with VERACODE.
00:47
Today, I'd like to introduce you to the Apple
00:51
Station security weakness known as information leakage.
00:55
To do this, I'm going to use an application called Very Insecure, a Web app we're building. In order to demonstrate a number of real security vulnerabilities,
01:03
let's get started.
01:07
The term information leakage can be used to describe a wide variety of issues. What they have in common is that each will cause a system tau accidentally disclose confidential information to an unauthorized party.
01:19
It is surprisingly common for applications to unintentionally disclosed sensitive information such as configuration details, software version numbers, internal logic or even their users private information
01:32
to an attacker seeking to exploit the application or other associated targets. All of this information is instrumental to their success.
01:40
Leaked information could even be leveraged is a precursor to other subsequent offenses, such as targeted spearfishing attacks.
01:48
Additionally, many government and industry regulations imposed severe penalties on organizations that failed to protect their users. Sensitive data.
01:56
For these and other reasons, it's wise not to overlook the possible risk of information leakage within your applications.
02:05
In this demonstration, I'll explain a few of the common ways that sensitive information can be leaked.
02:10
The 1st 1 takes the form of a stray command left within an HTML element on a certain page.
02:16
It would appear that a developer or someone similar wrote this comment to instruct an internal user on steps to take if an image file should fail to render
02:25
within this known, they disclosed the internal I P address of the applications content server.
02:31
If that's ever happened to contain any easily found vulnerabilities, and attacker would not hesitate to utilize them.
02:38
After all,
02:40
the first stage of pulling off a malicious exploit is usually to gather as much data like this as the attacker can discover.
02:47
Since any visitor to the page could view the contents of this document,
02:52
this would represent a quick and easy game for any assailant.
02:58
In the next example, our application has just run the vulnerable query in response to some request
03:04
before it does so. It makes a record of the event and writes the entire query to a log file.
03:09
This query contains valuable information for locating the sequel injection vulnerability that hides within this operation.
03:16
An attacker doesn't usually begin with all of the information that they need for manipulating a query, but they will not hesitate to harness information that an application freely shares about itself.
03:28
The process of constructing a sequel injection based explain quickly accelerates once the attacker is granted details aboutthe structure or format of underlying queries.
03:37
Information. Leaks into a log file can provide an attacker with detailed information on how to construct valid sequel queries to run against the back into database.
03:49
As a final example,
03:50
consider a log in page that provides the user with the different response based on whether they're Logan, Attempt was successful or not
03:58
invalid user name causes one message to appear. But a valid user name with an invalid password generates another
04:04
pages that issue different responses for different input. Values can also lead to information leakage if their designers air. Not careful.
04:12
In this case, if the user receives a different message for an incorrect user name or passport,
04:17
a malicious non user who began with no valid credentials would recognize once they've discovered a valid username,
04:24
they could even obtain user names at large by brute, forcing this log in page. Assuming that there is no lockout function.
04:30
Disclosing these user names, even passively disclosing them, constitutes information leakage and a breach of the users trust.
04:39
Information leakage is not limited to the forms presented in this demonstration.
04:44
Other examples could involve applications that display verbose ever messages to users or one that invents user's personal information into publicly viewable pages.
04:54
In summary, if an application accidentally reveal sensitive data, it may be used by an attacker to exploit the application itself or its users
05:03
to discover other applications, security threats and learn steps for preventing them. Please continue to watch our training videos or participate in or training courses.
05:14
This is Kevin Richard from Veracode. Thank you very much for watching
05:18
Valid information leakage Flaw has been detected in your application. The next step is to update your code in order to remediate it.
05:27
Click on any tab to see how to secure your code from the threat of information leakage.
05:31
Hello again.
05:32
This is Kevin Richard, security researcher with Veracode, and you've been watching are Upset editorial on information leakage
05:40
In the previous section, we revealed several ways in which an attacker might discover and exploit this vulnerability and consider the impact of leaving such threats unchecked.
05:49
Now that you've gained a basic understanding of information leakage, I'll explain how to address this risk.
05:57
Information leakage effects virtually every language and platform.
06:00
It accompanies a wide range of application risks, and its severity will vary with the type of information that is disclosed.
06:06
Even so, every remediation plan starts with the need to decide what information should be considered sensitive.
06:15
Let's demonstrate the general approach to remediation by revisiting the example of the log query
06:20
here. The method find matching products retrieves a list of products using the supplied product name to query the database
06:28
just after it's to find the application looks the query in its entirety.
06:31
It should now be apparent why this is hazardous. The log will expose the table and column names used in the database.
06:39
This directly facilitates a sequel injection attack, and the risk must be addressed before an attacker discovers this file.
06:46
Therefore, we will remove the query for the log entry and simply loved the user search term instead.
06:53
In general, the task is to consider which types of users should have access to which types of data
06:59
and to account for all instances in which sensitive data may be shared with them. Even unintentionally,
07:04
any information that is not necessary to the application to perform a task should be removed.
07:13
There are some additional steps to take in order to minimize the risk of information. Leakage
07:18
during the testing phase regularly forced the application to generate errors.
07:24
Applications that have not been tested in this way will almost certainly right unexpected ever output, which could contain unwanted information,
07:33
set up a standard exception handling system and default error messages so that unexpected errors do not disclose sensitive information
07:42
in production. Detailed Our handling should be disabled or limited for end users. There's usually no reason to show them things like debug information, stack traces or path information.
07:55
Because errors could originate from layers beyond the application layer, such as the database, our Web server make sure not to overlook the messages they produce
08:07
as a final note.
08:07
If of Erica's skin has reported this flaw in your application, but you can demonstrate that the information disclosed is not truly sensitive, then the flaw may be a candidate for mitigation by design.
08:18
Additionally, certain instances of this flaw that occur with a non production environments may be candidates for mitigation by network environment.
08:28
If you would like more information, please schedule a consultation call with our security consulting team or contact veracode support.
08:35
This has been Kevin Richard from Veracode. Thank you very much for your time.
08:43
Hello again.
08:45
This is Kevin Richard, security researcher with Veracode, and you've been watching are Upset tutorial on information leakage
08:52
in the previous section, we revealed several ways in which an attacker might discover and exploit this vulnerability and consider the impact of leaving such threats unchecked.
09:01
Now that you've gained a basic understanding of information leakage, I'll explain how to address this risk
09:07
information leakage effects virtually every language and platform.
09:13
It accompanies a wide range of application risks, and its severity will vary with the type of information that is disclosed.
09:18
Even so, every remediation plan starts with the need to decide what information should be considered sensitive.
09:26
Let's demonstrate a general approach to remediation by revisiting the example of the log query
09:33
here. The method find matching products retrieves a list of products using the supplied product name to query the database
09:39
just after it's to find the application looks the query in its entirety.
09:43
It should now be apparent why this is hazardous. The log will expose the table and column names used in the database.
09:50
This directly facilitates a sequel injection attack, and the risk must be addressed before an attacker discovers this file.
09:58
Therefore,
09:58
we will remove the query for the log entry and simply loved the user search term instead.
10:05
In general, the task is to consider which types of users should have access to which types of data
10:11
and to account for all instances in which sensitive data may be shared with them, even unintentionally,
10:16
any information that is not necessary to the application to perform a task should be removed.
10:24
There are some additional steps to take in order to minimize the risk of information. Leakage
10:31
during the testing phase regularly forced the application to generate errors.
10:35
Applications that have not been tested in this way will almost certainly right unexpected ever output, which could contain unwanted information,
10:46
set up a standard exception handling system and default ever messages so that unexpected errors do not disclose sensitive information
10:54
in production. Detailed Our handling should be disabled or limited for end users. There's usually no reason to show them things like debug, information, stock traces or path information.
11:07
Because errors can originate for layers beyond the application layer,
11:09
such as the database or Web server, make sure not to overlook the messages they produce
11:18
as a final note.
11:20
If of Erica's skin has reported this flaw in your application, but you can demonstrate that the information disclosed is not truly sensitive. Then the flaw may be a candidate for mitigation by design.
11:31
Additionally, certain instances of this flaw that occur with a non production environments may be candidates for mitigation by network environment.
11:39
If you would like more information, please schedule a consultation call with our security consulting team or contact veracode support.
11:48
This has been Kevin Richard from Veracode. Thank you very much for your time.
11:56
The scope of this course was not intended to cover every possible circumstance in which information leakage could arise.
12:01
Rather, it was designed to convey the basic idea of this vulnerability.
12:05
Further information is available through the following links.
12:11
Thank you for viewing this app. SEC tutorial on information leakage
Up Next
Secure Development, Programming, and Coding with Veracode
Learn about important secure coding methodologies including CRLF Injection, Directory Traversal, Information Leakage, Open Redirects, OS Command Injection, SQL Injection and Cross-site Scripting
Instructed By
veracode
Instructor
