[Owasp-guide] Follow-up on continuing to OWASP guide

Andrew van der Stock vanderaj at owasp.org
Thu Apr 24 11:31:50 EDT 2008


Yes, but I'd really like help!

The chapters themselves have good headings, so I don't want to lose  
those, but we need to change how the material is presented from a  
mixture of attacks, what not to do, and what to do, to simply being  
"What YOU have to do well for a secure application", and very little  

For each control, the outline needs to be re-done:

HEADING - Good description of the control
Intro text - what the control is
How important this control is based upon the value of the application  
(high, medium and low)
How ESAPI does it as a textual description... and how to use that  
ESAPI feature in your code (code snippets in PHP, J2EE and .NET)
... or if it doesn't, what to you need to do well
Why it is important to do this - a bullet point list of attacks,  
hyperlinked to the Top 10, Testing or Code review Guides in the OWASP  

Here's a worked example, using "Display a last login notification"

4.1.1 Display a last login notification

Users are an important part of your application's security. A last  
login banner should be displayed to the user at the least once after  
the user has logged in. The control should be easy to understand for  
an average user. If users can see when the application thinks they  
last logged in, the users should notice if someone has logged into the  
application more recently than they remember. In concert with a simple  
to use "Contact Us" or "Report a Problem" button or link nearby, they  
will report issues and thus provide a simple detection control.

This control is important for high and medium class applications, or  
any application that has a need for accountability.

ESAPI does not implement this feature, so it will be necessary to  
store the date and time of the last activity or login in the user's  
record, and present that in your application.

The following attacks are reduced in severity by this control:

Session hijacking resulting in a complete account compromise
Stealing of credentials
Brute force attacks against credentials

Obviously, this is much shorter than what we have today. It's a "what  
to do" action item that is easily understood and implementable by  
architects/designers/developers - which are the Guide's core audience.

There might be a few items of what not to do. It's important to tell  
people some things are security nightmares, but I don't want this  
section to dominate any chapter. For example, in Authentication, the  
what not to do would include questions and answers, like this:

4.2.1 Ineffective or Dangerous Mechanisms

The following mechanisms should never be implemented in any application:

Questions and Answers. Some questions may not be collected as they  
refer to other people who may still be alive (such as Mother's maiden  
name), and thus in many countries with strict privacy laws will  
require the other person's permission prior to collection. Some data  
may not be collected as it could be against the law or be strictly  
regulated, such as government IDs such as SSN, driver's license or  
passport numbers. Some questions are easily guessable (such as closed  
questions such as what is your favorite color). Some questions will be  
public record (such as the street where you first lived is found as  
part of the birth certificate held by Birth, Marriage and Death  
registries, or Hillary Clinton's mother's maiden name is Howell). Many  
folks use social networks and blogging extensively, and so some  
questions will never have a private answer, even if the data is up on  
the Internet only for a short time. As this questions and answers  
recovers access to an account, it is a username and password analog.  
Most IT security policies require one way encryption of passwords, and  
such it is likely that answers will have to be one way encrypted, and  
thus will not be visible to help desk personnel, and be difficult to  
get capitalization and punctuation correct unless the answer is a  
single word. As such, this mechanism is simply insufficient to protect  
the average person's account and should never be used.


On Apr 24, 2008, at 10:36 AM, blake at electronicrealm.com wrote:

> Hi Andrew,
> I heard you have picked up the ball on the guide. Thank you.
> Wanted to help out. Not sure who has been assigned what. But can you  
> steer me which section you need to help the most on?
> Thanks,
> Blake

Andrew van der Stock
Lead Author, OWASP Guide and OWASP Top 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-guide/attachments/20080424/4f2bb2a0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 3.png
Type: image/png
Size: 9598 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-guide/attachments/20080424/4f2bb2a0/attachment-0001.png 

More information about the Owasp-guide mailing list