nodeJS and Web APIs
Follow
Find
47.9K views | +7 today
 
Scooped by Srdjan Strbanovic
onto nodeJS and Web APIs
Scoop.it!

The Secure Web Series, Part 1: Securing Your Password Reset Mechanism

The Secure Web Series, Part 1: Securing Your Password Reset Mechanism | nodeJS and Web APIs | Scoop.it
Welcome to a new series on how to avoid common web application
vulnerabilities, called The Secure Web Series. In this series of posts,
I’ll be exploring some of the most common vulnerabilities we see in our
testing practice here at Fortify on Demand. The focus of the series will
be on vulnerabilities that aren’t easily identified via automation, as
these are harder to find using readily available tools and many testing
offerings tend to miss them during assessments. The target audience is
web developers and web application security testers. In each installment
of the series we’ll cover the following areas: The most common flaws we
see in the real world for this particular component of web
applicationsHow to avoid making each of those mistakesA list of best
practices for that componentIn this first installment, we'll be tallking
about vulnerabilities in the Password Reset Mechanism… The Insecure
Password Reset Mechanism Unfortunately, there are a myriad of ways to do
password resets insecurely: User account leakageSending the real
password in emailPredictable reset tokensFailure to expire reset
tokensAuto-logon after reset User Account Leakage Injection attacks are
noisy, take a long time, and have a decently high chance of getting
noticed. So one of the first things an attacker (or a good security
tester) will do on a site is look for a way to log in with a legitimate
account. Many websites have a form field like the one above on their
password reset page. Looks harmless enough, but most have an error in
it: When you enter a valid email address it gives you one message
(you’ll get an email shortly), and if you give it an email address
that’s not in the system it gives you another message (email address not
found). This means that an attacker can use automation to guess email
accounts, and come up with a list of valid users. From there you can
throw some quality password lists at it and probably walk right through
the front door with a valid account. Remediation The way to fix this is
to make the response to both situations identical (and that includes the
time it takes to come back with an answer). So instead of saying, yes or
no depending on the input, instead you ALWAYS say, "If your account was
found, you’ll receive an email shortly." That way we're not saying
whether or not it was found, only that if it was they'll get an email
soon. Sending Your Actual Password in Email One of the worst
vulnerabilities we see in applications’ password reset systems is when
the system just sends us our password in email. There are a couple of
problems with this: They just sent my password over the internet with no
encryptionHOW DID THEY HAVE MY CLEARTEXT PASSWORD?Bad on top of bad.
Remediation Avoid sending users their passwords, and instead have them
come to the website and create a new one. And if you absolutely MUST
send someone a password, it should be a temporary one that requires a
reset when they log in. You should never even know what a user’s real
password is, let alone send it to them over the Internet without
encryption. Predictable Reset Tokens Another serious problem we often
see with passwod reset systems is the use of predictable reset tokens.
This happens when developers either come up with their own, or use
someone else's homegrown solution for making the tokens. Predictable
tokens allow an attacker to make a large number of requests to the
password reset function, gather a large number of tokens, and then
analyze them for patterns. Once a pattern is found, the attacker can
then infer the next tokens to come from the system and reset victims'
passwords using those token links. Remediation Use a modern framework's
implementation of token generation. Never build your own. Failure to
Expire Reset Tokens Once a password reset token has been used it needs
to be rendered inactive within the system. We often find web
applications here at FoD that allow the user (or anyone with the link)
to continue resetting the password after it's already been reset once.
This is especially true because reset tokens are usually sent via email,
which often traverses the Internet unencrypted. For high security
websites you should consider an additional security measure: Notifying
the user if someone attempts to reuse the token. This can alert the user
to a potential compromise of their email account or some other type of
compromise of their security. Finally, if the password reset token is
not used within a certain amount of time it should expire. This period
of time should depend on the security level of the website, but between
10 and 90 minutes is fairly common. Remediation Ensure that reset tokens
are rendered invalid as soon as they are used, and for high security
sites consider alerting the user and possibly the security administation
team if there is an attempt to reuse one. Expire tokens that are not
used. Auto-logon After Reset Finally, after the user has successfully
reset her password, ensure that she's forced to return to the standard
login screen and authenticate with the new credentials. We see many
implementations that, upon the user completing their reset, simply drop
the user right into an authenticated session. This provides additional
surface area for attack of your authentication system (via logic attacks
errors and other methods) and should be avoided. Another reason to avoid
this is that all logins (attempted and successful) to your application
should be logged, and a backdoor into the app (without going through the
primary auth page) could leave a blind spot in your audit logs.
Remediation Ensure that all users are required to use the primary
authentication page after resetting their credentials. Don't allow any
backdoor entry through the password reset mechanism. Best Practices
Review Ok, so let's hit the main points again all in one place: Use
cryptographically strong password reset tokensExpire those tokens after
a successful useExpire tokens after 10-90 minutes--depending on the
security of the siteAlways reset the password on the website itself
rather than emailing the user a new oneEnsure you use HTTPS on the page
where you have users reset their passwordsDetect (and potentially
respond to) attempts to reuse reset tokenForce the user to explicitly
log in via the standard mechanism using their new credentials after the
password reset process has completed Conclusion Keep in mind this isn’t
a complete guide to security issues related to password reset
mechanisms, but it should get you thinking about some of the main errors
to avoid. Also be sure to come back for the next installment where we'll
cover Authentication Vulnerabilities. As always, feel free to reach out
with any questions via Twitter (@danielmiessler) or via email
(daniel.miessler@hp.com). hp.com/go/fortifyondemand : : Daniel Miessler
is a Practice Principal with Fortify on Demand based out of San
Francisco, California. His areas of expertise are web and mobile
application security testing and building application security programs
for the Global and Fortune 100. He can be reached at
daniel.miessler@hp.com and on Twitter at @danielmiessler.
more...
No comment yet.
nodeJS and Web APIs
about node.js and Web APIs
Your new post is loading...
Your new post is loading...
Scooped by Srdjan Strbanovic
Scoop.it!

Cloudshift - A Node.js App Framework for haXe Programmers - AMT Blog

Cloudshift - A Node.js App Framework for haXe Programmers - AMT Blog | nodeJS and Web APIs | Scoop.it
RT @NodeJsCommunity: Cloudshift - A Node.js App Framework for haXe Programmers http://t.co/yGLkECgk #OpenSource #Nodejs #HaXe http://t.co/oUiT0Kh6...
more...
No comment yet.
Suggested by Lanie
Scoop.it!

Free Cron Jobs | Online Webcron Service - EasyCron.com

Free Cron Jobs | Online Webcron Service - EasyCron.com | nodeJS and Web APIs | Scoop.it
EasyCron provides the most stable Cron Job Services. Here you can schedule cron jobs with execution logs, Email notifications, run time predictions and a bunch of other featuers!
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

The Most Common API Security Hacks of 2014

2014 was the year of the API security hack. Snapchat, Twitter, Tinder – these companies and more all experienced malicious API security attacks that compromised their users’ data, and as a result, their credibility. So we looked at the hard numbers this year to determine the most prevalent types of API hacks and who is most vulnerable to a security breach. Check out the stats below so you can keep your APIs safeguarded for 2015.
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

Roy Fielding on Versioning, Hypermedia, and REST

Roy Fielding on Versioning, Hypermedia, and REST | nodeJS and Web APIs | Scoop.it
Roy Fielding talks to Mike Amundsen about versioning on the Web, why hypermedia is a requirement in his REST style, the process of designing network software that can adapt over time, and the challenge of thinking at the scale of decades.
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

The Node Way - What is The Node Way?

The Node Way - What is The Node Way? | nodeJS and Web APIs | Scoop.it
Design patterns and best practices for building scaleable, maintainable and beautiful Node.js applications.
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

Moving from PhantomJS to node-webkit - Todd Wolfson

Transferring visual regression tests from PhantomJS to node-webkit for better node_modules/ support and more accurate screenshots.
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

Building a simple REST API using Node.js , Restify.js and MongoDB (Mongoose.js) – Part 3 – Defining a schema and using a Model

Building a simple REST API using Node.js , Restify.js and MongoDB (Mongoose.js) – Part 3 – Defining a schema and using a Model | nodeJS and Web APIs | Scoop.it
Reblogged on WordPress.com
more...
P1xt's curator insight, January 31, 2:26 PM

Restify looks interesting

Scooped by Srdjan Strbanovic
Scoop.it!

StrongLoop Arc aims to manage the whole Node.js API lifecycle - Gigaom

StrongLoop Arc aims to manage the whole Node.js API lifecycle - Gigaom | nodeJS and Web APIs | Scoop.it
As we know from the recent dustup around the forking of Node.js, people are passionate about that server-side JavaScript run-time environment.
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

Top 10 Mistakes Node.js Developers Make

Top 10 Mistakes Node.js Developers Make | nodeJS and Web APIs | Scoop.it
Node.js expert Alexandru Vladutu discusses some of the most common mistakes that developers make when working with Node.
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

Node.js Best Practices - Part 2

Node.js Best Practices - Part 2 | nodeJS and Web APIs | Scoop.it
The next chapter of node.js best practices, featuring pre-commit checks, JavaScript code style checker and configuration best practices...
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

BDD/TDD development from scratch with node.js/express

BDD/TDD development from scratch with node.js/express | nodeJS and Web APIs | Scoop.it
Clearly, the world is in dire need of another blogging engine, right? OK, perhaps not so much but I am very much in need of a website where I can show off my best work and a blog where I...
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

RestfulGit: an open source web service for accessing git data « Hulu Tech Blog

RestfulGit: an open source web service for accessing git data « Hulu Tech Blog | nodeJS and Web APIs | Scoop.it
more...
No comment yet.
Scooped by Srdjan Strbanovic
Scoop.it!

The Blockchain Application Stack

The Blockchain Application Stack | nodeJS and Web APIs | Scoop.it
Last week I led a workshop at NYU’s Bitcoin Hackathon, HackBit, where I talked about Bitcoin as a Protocol, alternative uses for the Blockchain, and a little bit about the challenges and opportunities...
more...
No comment yet.