This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
This vulnerability allows an attacker to accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system. Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code.
Using tools like Burp Suite to test for Security Misconfiguration
Further Reading:
OWASP Security Misconfiguration
Helmet: Express.js security with HTTP headers
npm-package-locks: An explanation of npm lockfiles
npm-shrinkwrap: Lock down dependency versions for publication
Body-parser - Node.js body parsing middleware: Limit middleware as part of the body-parser middleware.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
Howdy, we're glad to have you back for
the final stage, OWASP top 10 course.
0:04
In this final stage, we'll be covering
application misconfigurations,
0:09
the use of insecure third party
application components, and
0:13
insufficient logging and
monitoring of applications.
0:17
Now, let's dive into
security misconfiguration.
0:19
This vulnerability can allow an attacker
to access many things they shouldn't,
0:23
default accounts, unused pages, unpatched
code, unprotected files, and much more.
0:27
In general, when developers forget to
configure their applications properly,
0:34
many things can go wrong.
0:38
Even worse, configuration happens at
every level of the application stack,
0:40
the server, UI, database, and more.
0:44
That means developers of applications must
work together with whomever is deploying
0:47
the application to configure it properly.
0:51
Attacks on insecure configurations
can occur in many different ways, but
0:54
here's a few examples.
0:58
First, if you run your
applications as root,
1:00
then if it's compromised an attacker has
full access to the underlying server.
1:02
When files and directories have improper
permission set, an attacker might
1:07
be able to simply browse to that page in
the UI and access things they shouldn't.
1:11
Another issue could be if the server
leaks its version and other details,
1:16
allowing an attacker to find known bugs
online specific to that version and
1:19
attempt to exploit it.
1:23
Finally, if the request body is allowed to
be too large, an attacker could bring down
1:24
a site by uploading a huge file and
consuming all the resources of the site.
1:29
Now, how do you prevent these issues?
1:33
Well, the details depend on the chosen
implementation, language, framework and
1:36
the application.
1:40
But in many cases, these issues pop
up across lots of implementations
1:41
regardless of the language.
1:45
First, always use the latest stable
version of your application framework.
1:47
This prevents your application
getting hit by bugs from long ago, and
1:51
not patched until recent versions.
1:55
As we discussed earlier, also try to
never run your applications as root.
1:57
Furthermore, you should review
HTTP response headers to
2:01
prevent information leakage.
2:04
As you will see, Express and many other
server frameworks add an HTTP header,
2:06
by default, that tells the user what
the framework is running on the server.
2:11
You should also be using generic session
cookie names, which will put a stop to
2:15
attackers looking for the default
sensitive credentials of other users.
2:19
Other important configuration issues can
be addressed by limiting the request
2:22
body parameters.
2:26
Care should also be taken to vet
packages before using your applications,
2:27
as we'll discuss later.
2:31
As well as locking versions of packages
to prevent applications from breaking or
2:32
exposing flaws.
2:36
Finally, as we saw from preventing XSS and
2:37
CSRF, adding security specific
headers can go a long way.
2:41
In Node.js and JavaScript several of these
issues can be addressed directly with
2:45
existing libraries.
2:48
Remember, these same protections exist for
the back-end server framework for
2:50
nearly any language.
2:53
But once you know what to search for,
you'll easily find them.
2:55
To limit the HTTP request body size,
check out the limit middleware
2:58
that can be included with the Express.js
as part of the bodyParser package.
3:02
To lock packages to specific versions,
the npm-shrinkwrap package can be used.
3:06
To set specific HTTP headers, take a look
at Helmet, a very popular npm package
3:11
that sets headers to help prevent
issues like XSS and CSRF.
3:17
Finally, you should always change
the default names of session cookies,
3:20
which will at least stop an attacker from
immediately knowing which cookies to
3:24
use maliciously.
3:28
Before we move on to the next video,
let's see how this issue
3:30
occurs in the application that we've
been looking at throughout this course.
3:33
Let's investigate our application
to see what's exposed.
3:37
First, let's open up the developer
tools of our browser.
3:40
Here, we can look at the requests and
the responses individually.
3:44
Let's take a look at the request
response pair that loaded the dashboard.
3:47
We see here not only the session cookie,
but
3:51
also that our application
is running express.
3:53
Yikes, to address these issues, first,
we can disable the x powered by header,
3:56
which tells the browser what
the server was implemented in.
4:01
This should be done in
application initialization,
4:04
by modifying the main server file,
server.js.
4:07
Furthermore, we can change
the cookie name used for
4:19
the session token by changing the key
field on the express.session object,
4:21
which will change the name of the session
token to something less generic.
4:25
We also mentioned the Helmet library
earlier, which allows JavaScript
4:30
application to set many useful
HTTP headers for added security.
4:33
With the Helmet library,
setting these headers is easy.
4:38
We can prevent pages from
opening up in IFrames,
4:48
which can help prevent some
attacks such as click jacking.
4:52
We can prevent the browser
from caching certain pages.
5:01
We can enable CSP, or
content security policy,
5:07
which assists in preventing
the harmful effects of XSS attacks.
5:10
We can prevent the browser from loading
up our application in anything other
5:26
than HTTPS.
5:29
And finally,
5:30
we can prevent attackers from figuring out
the content type via sniffing request.
5:33
Be sure to check the other site
headers that you can add via Helmet.
5:38
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up