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: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: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: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: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: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
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: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
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: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