Time
1 hour 41 minutes
Difficulty
Beginner
CEU/CPE
2

Video Description

Open Redirects are a security flaw that attackers can exploit to scam a site's visitors. In this AppSec Tutorial, developers will see how Open Redirect flaws come about, learn how to know if this flaw threatens their software, and discover how to defend against it.

Video Transcription

00:06
up SEC tutorials open redirects
00:09
about this course.
00:11
Open redirects are a type of security vulnerability that can affect many Web applications.
00:17
Any time a system redirects traffic in an unsafe manner, it could potentially benefit malicious users who depend on such oversights to succeed in their goals.
00:26
In this course, you'll see some examples of how this weakness can arise and how it can be addressed
00:32
to get the most out of this course. If you haven't already done so, we recommend that you take our introduction to Web application Security Course first.
00:42
Hello and welcome to absent tutorials.
00:45
My name is Kevin Richard, and I'm a security researcher with VERACODE.
00:49
In this video, I'm going to introduce you to a security weakness called open redirects, or is that sometimes known on validated redirects and forwards?
00:59
Along the way, I'll be using an application called Very Insecure, a small Web app that we've built to contain an enormous number of security threats.
01:07
So let's get started.
01:11
If you've ever built a Web application that handled any amount of business logic, it probably involved the use of atleast one redirect our forward method.
01:19
Because these operations air so commonplace, many people aren't aware of a certain risk that can arise if they're used in an unsafe manner.
01:27
It may not stand out at first, but the page of my screen actually contains a typical example of an open redirect vulnerability.
01:34
Let's have a look at the Veracode home page link here at the bottom of my screen.
01:40
Whenever very insecure needs to direct the user to some external sight, it makes use of a redirect method like the one we see here in this location,
01:48
as one would expect. Once the user clicks this link, the page sends them to the location that is specified in the girl's single parameter.
01:57
Web applications also handle internal forwards in a similar fashion.
02:01
So where's the vulnerability and what we just saw?
02:05
It's not that the redirect opposes any concern by itself. This redirect has no secret powers on its own.
02:12
All the power lies in how I use it.
02:15
The link doesn't actually let me slip around the authentication on this page, nor on anyone else's log in page. This time, the risk is that the malicious user would use this like in a straightforward manner and wouldn't pass in any input that would cause it to behave unexpectedly,
02:30
but instead would use it in order to deceive another user of the application.
02:35
Let's pretend that this application was hosted on a domain that we recognized and trusted, say, very insecure dot or GE.
02:43
We want to get another user onto this page will steal your money dot or GE.
02:46
Most users would know better than to put their trust in such a suspicious looking to remain.
02:52
But a less experienced user or user in a hurry
02:55
might check only the domain name of the girl to see if the link is trustworthy, even if the earl gets longer and longer.
03:02
So what if we were to set the target of the redirect link on this page as our desired destination? This page will steal your money dot or GE, and convince someone else to click it.
03:14
Well. The domain names still appears benign, but it's plain to see what I'm trying to do here.
03:19
After all, the words steal your money tend to stand out.
03:23
So instead I'll go and feed my target link through a link shorter, like the one provided by Google, and use that link as the parameter value instead.
03:32
And if that still wasn't enough, there are plenty of other tricks I could use. Like taking the I p address associated with the target you, Earl, and converting it to hacks. A decimal foreman.
03:43
Because this text doesn't grab your attention.
03:46
This link which surely increase the number of users who would end up clicking on it if they were to see it in the right context, such as a fake email used in conjunction with a phishing scam.
03:55
If you click on this link
03:58
even though the host name was clearly very insecure dot or ge,
04:01
we've somehow landed on the domain. This page will steal your money. Don't. Argh!
04:05
The thing is, this page doesn't look any different from the one that we just saw.
04:10
And this is no accident, because if he used our sees, the domain clicks the leg, then sees the view they expected. Everything appears to be normal
04:18
and will respond to the instructions they see.
04:21
So it looks like the next step is to enter their credentials.
04:26
Too bad, because unbeknownst to the user, at the moment they do so that which they've typed is captured and sent back to me the owner of this rogue site.
04:35
In effect, I've stolen the trust of the users of the first sight placed in them and used it as a weapon against them.
04:43
In the real world. A user might also be exposed to extensive risk by a redirect to a page containing malware, which would then compromise the user's machine.
04:51
The user's interaction with your Web server may also then be compromised if the malware contains a key logging function or performs other kinds of attacks to steal credentials, personally identifiable information or other pieces of important data.
05:06
So remember
05:08
the attack that you just saw is merely one kind of on validated redirect attack.
05:12
A very code skin might report on variations other than the ones we saw today.
05:16
I encourage you to keep watching in order to learn how to prevent this threat or to fix it once it's been detected.
05:23
Thanks for watching and hope to see you soon.
05:28
It's a valid open redirect flaw has been detected in your application. The next step is to update your code to remediated. Click on any tab to see how to secure your code from the threat of open redirects
05:40
hello again and welcome back to our OPSEC tutorial on open redirects.
05:44
In the previous section, you saw an example of an open redirect vulnerability that could be used to successfully launched a phishing scam and steal credentials from users.
05:54
So now that you understand the threat posed by open redirects, I'll show you how you can address this concern.
06:00
Let's start by taking a look at the code that sits behind the vulnerable page.
06:04
Here. You'll notice that by sourcing the value of the target variable from the client, the application ends up allowing untrusted data to pass into server side code, yet fails to perform any check of that Davis validity prior to using it.
06:18
Any time we say untrusted data and applications security, we mean data that comes from sources whose integrity you don't know and therefore whose real intent you cannot trust.
06:30
In our example, that includes taking user supplied input from the U. R L. And storing it in a server side variable.
06:38
As a developer, I'd ask what is my intended use for this redirect method?
06:43
Is there ever a reason within the normal course of interacting with this website that a user would need to modify this link in order to access some destination.
06:51
Of course, there isn't
06:53
so there's ultimately no reason for the code to handle this operation in the way that it currently does.
06:59
Right now, the server said. Code defines the target variable as a value taken from the user's inbound request, then passes that value to the redirect method to be used as its target location.
07:10
This is the code that allows the phishing scheme to take place.
07:14
So while we can do instead is to change the applications behavior so that it only allows targets to be selected from a group of destinations that we've defined in advance on the server side,
07:24
instead of letting it access any girl that he used, her types will change it so that we first to find all of the possible targets that the redirect function can use
07:32
in other words, will create a white list stuff than then a Simon set of map values to these targets.
07:39
Those values will now appear in the earl instead of the literal destination, and they will be mapped back to the predetermined targets that we first defined
07:47
the benefit of doing it This way is that an attacker can no longer trick someone into visiting any world that they type.
07:54
The redirect function now only works for the targets we've selected in advance,
07:58
which was how we always wanted it to behave.
08:01
We've just updated the code to reflect that intent.
08:05
There are a few basic fixes that can be adapted to address most open redirect flaws.
08:09
The first, and perhaps the most obvious, is to remove the use of forward or redirect all together
08:16
when this is not possible because it is, after all, a lot to ask.
08:20
Then avoid the use of user supplied parameters in determining the destination.
08:26
Otherwise, take the steps that you've just learned use a mapping value is the destination parameter instead of a euro or any substantive, You are Oh,
08:35
and you server side code to translate this mapping back to a target you Earl.
08:39
If this is not possible, see if you can validate the user supplied value according to a context that makes sense, such as mapping a certain domain name or keyword
08:50
as a final moment.
08:50
If a veracode skin has reported an instance of this flaw in your application, but you're able to demonstrate that the flaw has no real world security impact or is mitigated by a factor that the scanning engine did not recognize. Then the finding may be a candidate for mitigation by design.
09:07
If you would like more information, please schedule a consultation call with our security consulting team
09:13
or contact Jericho's support.
09:15
This has been Kevin Richard from Veracode. Thank you very much for your time.
09:20
Hello again and welcome back to our OPSEC tutorial on open redirects.
09:26
In the previous section, you saw an example of an open redirect vulnerability that could be used. It successfully launched a phishing scam and steal credentials from users.
09:35
So now that you understand the threat posed by open redirects, I'll show you how you can address this concern.
09:41
Let's start by taking a look at the code that sits behind the vulnerable page.
09:46
Here. You'll notice that by sourcing the value of the target variable from the client, the application ends up allowing untrusted data to pass into server side code, yet fails to perform any check of that Davis validity prior to using it.
10:01
Any time we say untrusted data and applications security, we mean data that comes from sources whose integrity you don't know and therefore whose real intent you cannot trust.
10:11
In our example, that includes taking user supplied input from the U. R L. And storing it in a server side variable.
10:18
As a developer, I'd ask, What is my intended use for this redirect method?
10:24
Is there ever a reason within the normal course of interacting with this website that a user would need to modify this link in order to access some destination?
10:33
Of course there isn't
10:35
so. There's ultimately no reason for the code to handle this operation in the way that it currently does.
10:39
Right now, the server said, code defines the target variable as a value taken from the user's inbound request, then passes that value to the redirect method to be used as its target location.
10:52
This is the code that allows the phishing scheme to take place.
10:56
So while we can do instead is to change the applications behavior so that it only allows targets to be selected from a group of destinations that we've defined in advance on the server side
11:05
instead of letting it access any girl that he used, her types will change it so that we first to find all of the possible targets that the redirect function can use,
11:15
in other words, will create a white list stuff than then a Simon set of map values to these targets.
11:20
Those values will now appear in the earl instead of the literal destination, and they will be mapped back to the predetermined targets that we first defined.
11:28
The benefit of doing it this way is that an attacker can no longer trick someone into visiting any world that they type.
11:35
The redirect function now only works for the targets we've selected in advance,
11:39
which was how we always wanted it to behave.
11:41
We've just updated the code to reflect that intent.
11:46
There are a few basic fixes that can be adapted to address most open redirect flaws.
11:52
The first, and perhaps the most obvious, is to remove the use of forward or redirect all together
11:58
when this is not possible, because it is, after all, a lot to ask.
12:03
Then avoid the use of user supplied parameters in determining the destination.
12:07
Otherwise, take the steps that you've just learned use a mapping value is the destination parameter instead of a euro or any substantive you are Oh,
12:16
and you server side code to translate this mapping back to a target you Earl.
12:20
If this is not possible, see if you can validate the user supplied value according to a context that makes sense, such as mapping a certain domain name or keyword
12:31
as a final note.
12:31
If a veracode skin has reported an instance of this flaw in your application, but you're able to demonstrate that the flaw has no real world security impact or is mitigated by a factor that the scanning engine did not recognize, then the finding may be a candidate for mitigation by design.
12:48
If you would like more information, please schedule a consultation call with our security consulting team or contact Jericho's support.
12:56
This has been Kevin Richard from Veracode. Thank you very much for your time.
13:01
The scope of this course was not intended to cover every possible circumstance in which opened redirects could arise. Rather, it was designed to convey the basic idea of this vulnerability.
13:11
Further information is available through the following links.
13:16
Thank you for viewing this out sectorial on open redirects

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

Instructor Profile Image
veracode
Instructor