In this lesson,
we're going to discuss broken authentication
and insecure references,
and how these vulnerabilities
are exploited by threat actors.
First, we have broken authentication.
Broken authentication is a software vulnerability,
where the authentication mechanisms are insecure
and can allow the attacker to gain entry.
If the application doesn't implement
secure authentication mechanisms,
then a threat actor is going to be able
to exploit the system
to compromise a user session or their password.
This exploitation usually occurs
because the passwords being used are weak or easily guessed,
or because the authentication system itself
was programmed insecurely
and has several coding flaws within it.
For example, I've come across
some broken authentication mechanisms in my assessments
that include mechanisms
that display the credentials in clear text,
or they used weak randomization
when defining their session tokens.
I've also seen some that permit brute force login requests
without any kind of lockout or timeout feature.
For example, if your program uses weak credentials,
such as a person's email address
and a four-digit PIN to identify the user,
this is pretty weak as an authentication system.
After all, any four-digit PIN
can be cracked with just 1,000 attempts
because there's only 1,000 variations of that PIN.
So, the attacker can quickly brute force their way through
and find the right one.
Another weak authentication mechanism
that could be exploited
would involve your password reset method.
If your system uses a knowledge-based factor,
like the person's birthday, place of birth,
or state they register to vote in,
all of those are considered weak factors of authentication
because it can easily be found online for most people.
Now, another weakness is in terms of session identifiers
that are being used
after somebody authenticates to your application.
When you're dealing with session identifiers,
you need to ensure they're truly random
and they're not passed as part of your URL parameters
because these can easily be captured by a network sniffer
or an eavesdropping attacker.
Now, let's pretend you're going to log into my website
at members.diontraining.com,
and let's say we're using improper session tracking,
and this could be a vulnerability.
Now, once you log in
using your username and password to authenticate,
you're going to be issued a random session ID
to track your movements
so we know which student is on which page or which lesson.
Now, if this ID is being passed as a parameter
to our server through the URL, it'll look something
like members.diontraining.com/courses/ID=1234,
and this would be an extremely insecure way of doing things,
so you really don't want to do it.
But follow me for this example.
Now, if somebody copied that link,
they could simply enter it into their web browser
and take over your session
because that session ID is being shown right there
as a URL parameter.
For this reason, session IDs should never be passed
as part of the URL parameters
because those can be seen when looking at network traffic,
even if the traffic was secured using a TLS tunnel.
Now, broken authentication
is one of the biggest vulnerabilities
that are found in the Open Web Application Security Project,
known as OWASP,
in their annual top 10 biggest vulnerabilities.
To protect against broken authentication,
you should follow these seven recommendations.
First, you should utilize multi-factor authentication.
Second, you should never use default credentials
in any application.
Third, you should verify that passwords are strong
and not found on published password exploitation lists.
Fourth, you should use limits or delays
to slow failed login attempts and brute force attacks.
Fifth, you should use server side session management
as well as using long randomized session identifiers.
Sixth, you should never pass a session identifier
as a URL parameter.
And seven, you should always implement session timeouts
and expiring session identifications
to prevent reuse of previously authenticated sessions
by your users.
Now, the second major vulnerability
we're going to discuss in this lesson
is known as Insecure references,
also known as Insecure Object Reference,
or an Insecure Direct Object Reference.
Now, an Insecure Direct Object Reference
is used by a threat actor to manipulate the URL
to gain access to a resource
without requiring proper authentication
because of a weak access control system that's in place.
This is commonly used to access data inside of a database
through an insecure web application.
Now, let me provide you
with a good example of this vulnerability.
Let's pretend I started my own bank called The Bank of Dion.
Now, a bunch of my students decide to sign up for my bank,
and each one is going to be issued their own account number.
Now, anytime a student wants to access their bank account,
they're going to log in at bankofdion.com,
and then they'll be redirected
to their own personalized page.
Something like Bank of dion.com/account.php?acct=1234,
and then their account will be displayed to the screen.
Notice, the URL here
contains an Insecure Direct Object Reference
to that student's account.
In this case, it says acct=1234.
Now, if I changed that and went from 1234 to 4321,
I'm going to get access to somebody else's
account information.
This is because the account number
is being passed insecurely as a URL parameter
and directly linked to a specific account and user.
This is what we're referring to
with an insecure direct object reference,
and it should never be used this way.
So, how do you prevent insecure direct object references?
Well, the first thing to do
is always use secure coding practices.
This is an area that can be completely eliminated
through the proper design of your web applications
and building a proper authentication
and reference techniques.
Second, you should always implement
proper access control techniques in your applications
to verify a user is authorized to access a specific object,
even if you're using direct references.
For example, if I was logged in as Jason
in the Bank of Dion example
and I tried to change my account from 1234 to 4321,
it should give me an error
because that account is owned by Tamara and not Jason.
But again, it's much better to ensure
you don't use direct object references in the first place.
So this again goes back
to using proper secure coding techniques
and best practices to prevent this type of exploitation.