(Read to the tune of "Rage Against the Machine : Killing in the Name")
1) I would defeat SQL Injection. This would be a multi-phased plan focusing on programmer tools and programmer training. The main use of any Federal funding I could secure would be to build the worlds best open source SQL Escaping library so legacy code could be retrofitted.
2) I would lobby the Fed's to create a new branch of the military. ARMY - NAVY - AIRFORCE - CYBERFORCE - MARINES. The problem is that big, and we are losing the game.
3) I would take copious notes from day 1. This is a thankless job with heaps of responsibility and absolutely no power. Might as well get a good book deal out of the experience.
Wednesday, December 23, 2009
Sunday, November 22, 2009
OWASP Top 5 rc1 released!
I'm very impressed with the latest OWASP Top 10 2010 release candidate . But if a 10 item list is to long for you in this era of 140 character tweets, I present to you the unauthorized reductionistic OWASP Top 5.
And the OWASP Top 5 is:
1) Injection Flaws
2) Broken Authentication
3) Broken Access Control
4) Broken Encryption
5) Security Misconfiguration
The OWASP Top 5 team felt that A2 (XSS) could be considered to be another kind of injection problem. Like most injection flaws, XSS is controlled by contextual encoding.
A4 (Direct Object Reference), A5 (CSRF), A6 (Failure to Restrict URL Access) and A8 (Unvalidated Redirects and Forwards) could be considered to be classes of access control/authorization flaws. I think that A4/A6/A8 all easily fit into the access control category. But CSRF as just an access control problem? Yes! Authentication validates WHO you are. Authorization/Access Control validates WHAT can you do. CSRF tokens are just a piece of that task/activity validation.
A9 (Insecure Cryptographic Storage) and A10 (Insufficient Transport Layer Security) are 2 sides of the same data-encryption-lifecycle.
Hat's off to the OWASP Top Ten team. This brief reductionism is just a form of OWASP Top 10 flattery! :)
Saturday, November 14, 2009
Hardware Security
A recent article in "Foreign Affairs" magazine titled "Securing the Information Highway" (co-authored by General Clarke and Peter Levin) caught my attention. Interesting stuff. Focuses on hardware security.
http://www.foreignaffairs.com/articles/65499/wesley-k-clark-and-peter-l-levin/securing-the-information-highway
Their basic thesis is that there is just no way possible to stop the threat of "electronic infiltration, data theft, and hardware sabotage" and that securing the nation infrastructure is "neither cost effective or technically feasible".
They suggest:
1) Risk Management : "US must develop an integrated strategy that addresses ... the sprawling communications network to the individual chips inside computers"
2) Diversification of the country's digital infrastructure
3) Secure the hardware supply chain
Worthwhile read.
http://www.foreignaffairs.com/articles/65499/wesley-k-clark-and-peter-l-levin/securing-the-information-highway
Their basic thesis is that there is just no way possible to stop the threat of "electronic infiltration, data theft, and hardware sabotage" and that securing the nation infrastructure is "neither cost effective or technically feasible".
They suggest:
1) Risk Management : "US must develop an integrated strategy that addresses ... the sprawling communications network to the individual chips inside computers"
2) Diversification of the country's digital infrastructure
3) Secure the hardware supply chain
Worthwhile read.
Monday, August 17, 2009
justifying the focus on insider threat
Thank you to Mat Caughron at mat@phpconsulting.com for authoring this most excellent blog entry.
It is common to have the insider threat dismissed as a scare tactic or
worst-case-scenario and I believe this is a mistake.
We are all about the business value of risk.
Most enterprise companies have to protect themselves from malicious
insiders at all times and this affects the design of their software,
specifically the need for least privilege and generally all
requirements surrounding logging and internal controls. My thinking
is that if you want to have a seat at the table during the beginning
phases of the software development life cycle, it is best to master
the concerns and business needs imposed by this type of risk.
Granted, our industry seems to generate snake oil by the barrel, which
is all the more reason for us to take these threats seriously and
calmly seek publicly documented data on real cases.
Indeed, one would hope the information security professional is
someone who helps to establish the boundaries of trust in systems
being built, not someone who vacuums up the pieces of broken projects,
however well such housekeeping pays.
Some references not yet mentioned in this thread:
Report from 1999 by NSTISSAM:
http://www.cnss.gov/Assets/pdf/nstissam_infosec_1-99.pdf
Focus is on mechanisms more than specific incidents though a few are mentioned.
U^S3 report with Carnegie Mellon on insider threat, focus on
infrastructure and financial services industries, dated 2004/05/08:
http://www.secretservice.gov/ntac/its_report_050516.pdf
http://www.secretservice.gov/ntac/its_report_040820.pdf
http://www.treasury.gov/usss/ntac/gov%20ExecSummary%202008_ 0108.pdf
Each sampling set is around 50 incidents or less.
Department of Energy is grappling with this as the disruptions from
insiders could be high impact:
http://www.cio.energy.gov/documents/Tues_1400_SalonII_ Randall.pdf
Belani / Wilson web application incident response and forensics
considers insider threats with two great examples:
www.blackhat.com/presentations/bh-usa-06/BH-US- 06-Willis.pdf
Also presented in Seattle at an OWASP chapter meeting.
None of these reports, however, can compare in detail to the data set
of the Privacy Rights Clearinghouse' chronological list of data
breaches.
http://www.privacyrights.org/ar/ChronDataBreaches.htm
Until about 2006, the PRC list identified inside threat incidents as
"Dishonest insider." After that, the number of employee instigated
events is described with greater detail but is therefore harder to
search. A quick look here should be enough to convince most on this
webappsec list that the impact from insider threats is not
insignificant.
As software security professionals, we can help to mitigate insider
threat problems and our value in doing so should not be
underestimated.
The commonplace nature of OWASP-top-ten type flaws should not prevent
us from acknowledging their utility in the hands of a malicious
employee, developer, manager, etc.
Mat Caughron CISSP
(408) 910-1266
worst-case-scenario and I believe this is a mistake.
We are all about the business value of risk.
Most enterprise companies have to protect themselves from malicious
insiders at all times and this affects the design of their software,
specifically the need for least privilege and generally all
requirements surrounding logging and internal controls. My thinking
is that if you want to have a seat at the table during the beginning
phases of the software development life cycle, it is best to master
the concerns and business needs imposed by this type of risk.
Granted, our industry seems to generate snake oil by the barrel, which
is all the more reason for us to take these threats seriously and
calmly seek publicly documented data on real cases.
Indeed, one would hope the information security professional is
someone who helps to establish the boundaries of trust in systems
being built, not someone who vacuums up the pieces of broken projects,
however well such housekeeping pays.
Some references not yet mentioned in this thread:
Report from 1999 by NSTISSAM:
http://www.cnss.gov/Assets/
Focus is on mechanisms more than specific incidents though a few are mentioned.
U^S3 report with Carnegie Mellon on insider threat, focus on
infrastructure and financial services industries, dated 2004/05/08:
http://www.secretservice.gov/
http://www.secretservice.gov/
http://www.treasury.gov/usss/
Each sampling set is around 50 incidents or less.
Department of Energy is grappling with this as the disruptions from
insiders could be high impact:
http://www.cio.energy.gov/
Belani / Wilson web application incident response and forensics
considers insider threats with two great examples:
www.blackhat.com/
Also presented in Seattle at an OWASP chapter meeting.
None of these reports, however, can compare in detail to the data set
of the Privacy Rights Clearinghouse' chronological list of data
breaches.
http://www.privacyrights.org/
Until about 2006, the PRC list identified inside threat incidents as
"Dishonest insider." After that, the number of employee instigated
events is described with greater detail but is therefore harder to
search. A quick look here should be enough to convince most on this
webappsec list that the impact from insider threats is not
insignificant.
As software security professionals, we can help to mitigate insider
threat problems and our value in doing so should not be
underestimated.
The commonplace nature of OWASP-top-ten type flaws should not prevent
us from acknowledging their utility in the hands of a malicious
employee, developer, manager, etc.
Mat Caughron CISSP
(408) 910-1266
mat@phpconsulting.com
Sunday, August 9, 2009
When to use OWASP AntiSamy?
OWASP AntiSamy is a software engineering tool that allows a programmer to verify user-driven HTML/CSS input against a whitelist policy to ensure that is does not contain XSS.
But when do you use it?
But when do you use it?
1) If you accept "normal text data" from a user, then
a) (input validation) Use the ESAPI validator for input valiation (functions OTHER than getValidSafeHTML)
b) (output encoding) Use the ESAPI encoding library for contextual output encoding when displaying dynamic data in a web browser
1. encodeForHTML
2. encodeForJavascript
3. encodeForHTMLEntity
4. encodeForCSS
2) If you accept HTML from a user, you need to use AntiSamy
a) (input validation) You must validate and CHANGE (make it safer) HTML that you accept from a user with AntiSamy (which can be called via ESAPI - getValidSafeHTML)
b) (output translation) You can optionally use AntySamy for output translation (it does not encode; it only makes HTML "safer")
1. This is crucial when you have legacy HTML in your data storage mechanism that may still contain XSS
Saturday, August 8, 2009
Real world cookie length limits
Daniel Stenberg recently posted some interesting test code and browser results to http-state@ietf.org describing the maximum amount of data that can be stored in a cookie:
****
... I just went ahead and wrote a CGI script that redirects to itself and grows a
cookie and stores its length in a URL field like "cookie.cgi?len=200" until
the length in the URL and the actual cookie length no longer matches.
Here's a few results from various browsers:
Firefox 3.0.12: 4000
Firefox 3.5: 4000
curl 7.19.5: 4999
IE 8: 5000
Opera 10.00 beta: 4000
Android 1.5 browser: 4000
Chrome 3.0.195.6: 4000
Wget 1.11.4: 7000[*]
mobile safari (iphone): 8000
lynx 2.8.7dev.9: 4000
I think we can safely say that most browsers support at least 4000 characters
cookie contents.
[*] = this reports "500 Internal Server Error" on 8000, which I don't
understand why but haven't bothered much more about.
The test is live here: http://daniel.haxx.se/test/longcookie.cgi Feel free to
use it if you want to try out other browsers, without torturing it of course!
And the perl script that runs it looks like this:
require "CGI.pm";
$len = CGI::param('len');
$c = CGI::cookie('data');
print "Content-Type: text/html\n";
if($len == length($c)) {
$c .= "A" x 1000;
$len += 1000;
print "Set-Cookie: data=$c\n";
print "Location: longcookie.cgi?len=$len\n";
print "\nmoo\n";
}
else {
printf "\nMax cookie length: %d\n", length($c);
}
****
... I just went ahead and wrote a CGI script that redirects to itself and grows a
cookie and stores its length in a URL field like "cookie.cgi?len=200" until
the length in the URL and the actual cookie length no longer matches.
Here's a few results from various browsers:
Firefox 3.0.12: 4000
Firefox 3.5: 4000
curl 7.19.5: 4999
IE 8: 5000
Opera 10.00 beta: 4000
Android 1.5 browser: 4000
Chrome 3.0.195.6: 4000
Wget 1.11.4: 7000[*]
mobile safari (iphone): 8000
lynx 2.8.7dev.9: 4000
I think we can safely say that most browsers support at least 4000 characters
cookie contents.
[*] = this reports "500 Internal Server Error" on 8000, which I don't
understand why but haven't bothered much more about.
The test is live here: http://daniel.haxx.se/test/longcookie.cgi Feel free to
use it if you want to try out other browsers, without torturing it of course!
And the perl script that runs it looks like this:
require "CGI.pm";
$len = CGI::param('len');
$c = CGI::cookie('data');
print "Content-Type: text/html\n";
if($len == length($c)) {
$c .= "A" x 1000;
$len += 1000;
print "Set-Cookie: data=$c\n";
print "Location: longcookie.cgi?len=$len\n";
print "\nmoo\n";
}
else {
printf "\nMax cookie length: %d\n", length($c);
}
Saturday, July 18, 2009
Open letter to the Struts 1.x team on AUTOCOMPLETE
I'm a big fan of Struts 1.3.x. I currently use Struts 1.3.10, the latest release of the 1.x Struts line.
I would like the ability to disable autocomplete in an HTML form. Sadly (from a security perspective), most every browser enables autocomplete by default. We need to explicitly attribute our form html with autocomplete="off" - in both the form and form element tags of HTML 4.01+ pages. This is a very basic security protection. Wanting to prevent the browser from caching credit card numbers, PII and other critical user data is a no-brainier; appsec 101.
Now, the recent 1.3.10 release made a great stride in this direction. Finally for the first time the main Struts 1.3.x branch supports the autocomplete tag (which defensive coders need - just to disable this feature via html!). But it's still not enabled by default in Struts! I need to modify the struts tld xml file in order to enable the autocomplete form and form element attribute; which takes me off the main branch of Struts 1.3.x.
I implore you to consider enabling autocomplete by default, so we can turn it off - without having to customize our version of struts 1.3.x! The best security is "secured by default", and this request moves us in that direction.
Jim Manico
OWASP, Intrinsic Security Working Group
Sunday, June 28, 2009
ESAPI Logging
The OWASP ESAPI Logging interface is a security-centric but thin abstraction on top of traditional high-performance logging API's. There are both Log4j and native Java Logging default ESAPI logging implementations. The Log4j implementation is especially mature.
The logging interface of the OWASP ESAPI library pre-defines 4 types of log files entries specific to the glory of security monitoring.
public static final EventType ....
SECURITY_SUCCESS = new EventType( "SECURITY SUCCESS", true);
SECURITY_FAILURE = new EventType( "SECURITY FAILURE", false);
EVENT_SUCCESS = new EventType( "EVENT SUCCESS", true);
EVENT_FAILURE = new EventType( "EVENT FAILURE", false);
Attributing every log entry with a security type is fundamental to ESAPI. Your implementation of ESAPI can extend or change this list if desired.
ESAPI also supports a hierarchy of logging levels which can be configured at runtime to determine the severity of events that are logged, so that those log entries below the current threshold that are discarded. This is a common logging API feature and includes the following severity levels (fatal, error, warning, info, debug, trace).
The ESAPI team considered simply adding a security severity level to Log4J, but decided that was not enough. We wanted to force a programmer to tag every log entry as a security event (or not), regardless of severity level. We did not add yet another logging abstraction to your life lightly.
The reference implementations also includes the following protections:
- encodes any CRLF characters included in log data in order to prevent log injection attacks
- optionally encodes HTML characters into the HTML entity to protect web based log viewing software
- provides a mechanism to log session ids referentially so that sessions can be tracked in log files without exposing real session identifiers that could be used to hijack active sessions
- provides a mechanism to automatically log HTTP post/get variables while allowing for masking of passwords and other security-critical information that should not be logged
Much of this is configurable in ESAPI.properties
ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
#ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory
Specify your application name if you wish to log it.
Logger.ApplicationName=ARMS
# If you use an HTML log viewer that does not properly HTML escape
# log data, you can set LogEncodingRequired to true
Logger.LogEncodingRequired=false
Logger.LogApplicationName=false
Logger.LogServerIP=false
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
Logger.LogFileName=ARMS_ESAPI_LOGFILE
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)
Logger.MaxLogFileSize=10000000
#ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory
Specify your application name if you wish to log it.
Logger.ApplicationName=ARMS
# If you use an HTML log viewer that does not properly HTML escape
# log data, you can set LogEncodingRequired to true
Logger.LogEncodingRequired=false
Logger.LogApplicationName=false
Logger.LogServerIP=false
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
Logger.LogFileName=ARMS_ESAPI_LOGFILE
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)
Logger.MaxLogFileSize=10000000
So now you want to (securely) log. Right on. Simply specify a logger in each class that requires logging:
private final Logger logger = ESAPI.getLogger(SimpleESAPIFilter.class.getName());
And log away!
logger.error(Logger.SECURITY_FAILURE, "session has expired, log out user");
Here is an example of a log entry from one of my projects at Aspect. I'm not deploying on a cluster, yet, so I supressed the server IP, port and appName via ESAPI.properties.
2009-06-29 05:48:25,281 WARN IntrusionDetector SECURITY FAILURE Anonymous:0@unknown:unknown Incorrect password provided for dave
org.owasp.esapi.errors.ValidationException: Login failed
at com.aspectsecurity.arms.web.SimpleESAPIFilter.doFilter(SimpleESAPIFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.web.actions.ARMSBaseAction EVENT SUCCESS Anonymous:0@unknown:270186 ENTRY POINT FOR ALL ACTIONS: 1246268905281
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 START assertAuthorizedForAction : action=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 ACCESS GRANTED assertAuthorizedForAction completeActionName=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction IS NOT MANAGED, SO ALLOW GLOBAL ACCESS
org.owasp.esapi.errors.ValidationException: Login failed
at com.aspectsecurity.arms.web.SimpleESAPIFilter.doFilter(SimpleESAPIFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.web.actions.ARMSBaseAction EVENT SUCCESS Anonymous:0@unknown:270186 ENTRY POINT FOR ALL ACTIONS: 1246268905281
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 START assertAuthorizedForAction : action=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 ACCESS GRANTED assertAuthorizedForAction completeActionName=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction IS NOT MANAGED, SO ALLOW GLOBAL ACCESS
Thursday, June 25, 2009
One file to secure them all
Can you imagine having a WebAppSec program for your company that standardized on a open source secure code library, which was vetted by many smart people, and had several supporting tools available that could be used to ensure its use? I can....
Jeff is getting close to releasing ESAPI 2.0. I was checking out the new ESAPI default configuration file, checking in a little bit of cleanup, and was very taken aback by all of the rich appsec defense categories that it covers.
# Properties file for OWASP Enterprise Security API (ESAPI)
# You can find more information about ESAPI
# http://www.owasp.org/index.php/ESAPI
#
# WARNING: Operating system protection should be used to lock down the .esapi
# resources directory and all the files inside. Note that if you are using file-based
# implementations that some files may need to be read-write as they get
# updated dynamically.
#
# Before using, be sure to update the MasterKey and MasterSalt as described below.
#
#===========================================================================
# ESAPI Configuration
#
# ESAPI is designed to be easily extensible. You can use the reference implementation
# or implement your own providers to take advantage of your enterprise's security
# infrastructure. The functions in ESAPI are referenced using the ESAPI locator, like:
#
# ESAPI.encryptor().encrypt( "Secret message" );
#
# Below you can specify the classname for the provider that you wish to use in your
# application. The only requirement is that it implement the appropriate ESAPI interface.
# This allows you to switch security implementations in the future without rewriting the
# entire application.
#
# DefaultAccessController requires ESAPI-AccessControlPolicy.xml in .esapi directory
ESAPI.AccessControl=org.owasp.esapi.reference.accesscontrol.DefaultAccessController
# FileBasedAuthenticator requires users.txt file in .esapi directory
ESAPI.Authenticator=org.owasp.esapi.reference.FileBasedAuthenticator
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
ESAPI.Encryptor=org.owasp.esapi.reference.JavaEncryptor
ESAPI.Executor=org.owasp.esapi.reference.DefaultExecutor
ESAPI.HTTPUtilities=org.owasp.esapi.reference.DefaultHTTPUtilities
ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector
# Log4JFactory Requires log4j.xml or log4j.properties in classpath - http://www.laliluna.de/log4j-tutorial.html
ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
#ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory
ESAPI.Randomizer=org.owasp.esapi.reference.DefaultRandomizer
ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator
#===========================================================================
# ESAPI Authenticator
#
Authenticator.AllowedLoginAttempts=3
Authenticator.MaxOldPasswordHashes=13
Authenticator.UsernameParameterName=username
Authenticator.PasswordParameterName=password
# RememberTokenDuration (in days)
Authenticator.RememberTokenDuration=14
# Session Timeouts (in minutes)
Authenticator.IdleTimeoutDuration=20
Authenticator.AbsoluteTimeoutDuration=120
#===========================================================================
# ESAPI Encryption
#
# The ESAPI Encryptor provides basic cryptographic functions with a simplified API.
# To get started, generate a new key using java -classpath esapi.jar org.owasp.esapi.reference.JavaEncryptor
# There is not currently any support for key rotation, so be careful when changing your key and salt as it
# will invalidate all signed, encrypted, and hashed data.
#
# WARNING: Not all combinations of algorithms and key lengths are supported.
# If you choose to use a key length greater than 128 (and you should), you must download the
# unlimited strength policy files and install in the lib directory of your JRE/JDK.
# See http://java.sun.com/javase/downloads/index.jsp for more information.
#
Encryptor.MasterKey=pJhlri8JbuFYDgkqtHmm9s0Ziug2PE7ovZDyEPm4j14=
Encryptor.MasterSalt=SbftnvmEWD5ZHHP+pX3fqugNysc=
# AES is the most widely used and strongest encryption algorithm
Encryptor.EncryptionKeyLength=256
Encryptor.EncryptionAlgorithm=AES
# Do not use DES except in a legacy situation
#Encryptor.EncryptionKeyLength=56
#Encryptor.EncryptionAlgorithm=DES
# TripleDES is considered strong enough for most purposes
#Encryptor.EncryptionKeyLength=168
#Encryptor.EncryptionAlgorithm=DESede
Encryptor.HashAlgorithm=SHA-512
Encryptor.HashIterations=1024
Encryptor.DigitalSignatureAlgorithm=DSA
Encryptor.DigitalSignatureKeyLength=1024
Encryptor.RandomAlgorithm=SHA1PRNG
Encryptor.CharacterEncoding=UTF-8
#===========================================================================
# ESAPI HttpUtilties
#
# The HttpUtilities provide basic protections to HTTP requests and responses. Primarily these methods
# protect against malicious data from attackers, such as unprintable characters, escaped characters,
# and other simple attacks. The HttpUtilities also provides utility methods for dealing with cookies,
# headers, and CSRF tokens.
#
# Default file upload location (remember to escape backslashes with \\)
HttpUtilities.UploadDir=C:\\ESAPI\\testUpload
# Force HTTP only on all cookies in ESAPI SafeRequest
HttpUtilities.ForceHTTPOnly=false
# File upload configuration
HttpUtilities.ApprovedUploadExtensions=.zip,.pdf,.doc,.docx,.ppt,.pptx,.tar,.gz,.tgz,.rar,.war,.jar,.ear,.xls,.rtf,.properties,.java,.class,.txt,.xml,.jsp,.jsf,.exe,.dll
HttpUtilities.MaxUploadFileBytes=500000000
# Using UTF-8 throughout your stack is highly recommended. That includes your database driver,
# container, and any other technologies you may be using. Failure to do this may expose you
# to Unicode transcoding injection attacks. Use of UTF-8 does not hinder internationalization.
HttpUtilities.ResponseContentType=text/html; charset=UTF-8
#===========================================================================
# ESAPI Executor
Executor.WorkingDirectory=C:\\Windows\\Temp
Executor.ApprovedExecutables=C:\\Windows\\System32\\cmd.exe,C:\\Windows\\System32\\runas.exe
#===========================================================================
# ESAPI Logging
# Set the application name if these logs are combined with other applications
Logger.ApplicationName=ESAPITest
# If you use an HTML log viewer that does not properly HTML escape log data, you can set LogEncodingRequired to true
Logger.LogEncodingRequired=false
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
Logger.LogFileName=ESAPI_logging_file
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)
Logger.MaxLogFileSize=10000000
#===========================================================================
# ESAPI Intrusion Detection
#
# Each event has a base to which .count, .interval, and .action are added
# The IntrusionException will fire if we receive "count" events within "interval" seconds
# The IntrusionDetector is configurable to take the following actions: log, logout, and disable
# (multiple actions separated by commas are allowed e.g. event.test.actions=log,disable
#
# Custom Events
# Names must start with "event." as the base
# Use IntrusionDetector.addEvent( "test" ) in your code to trigger "event.test" here
#
IntrusionDetector.event.test.count=2
IntrusionDetector.event.test.interval=10
IntrusionDetector.event.test.actions=disable,log
# Exception Events
# All EnterpriseSecurityExceptions are registered automatically
# Call IntrusionDetector.getInstance().addException(e) for Exceptions that do not extend EnterpriseSecurityException
# Use the fully qualified classname of the exception as the base
# any intrusion is an attack
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.count=1
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.interval=1
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.actions=log,disable,logout
# for test purposes
IntrusionDetector.org.owasp.esapi.errors.IntegrityException.count=10
IntrusionDetector.org.owasp.esapi.errors.IntegrityException.interval=5
IntrusionDetector.org.owasp.esapi.errors.IntegrityException.actions=log,disable,logout
# rapid validation errors indicate scans or attacks in progress
# org.owasp.esapi.errors.ValidationException.count=10
# org.owasp.esapi.errors.ValidationException.interval=10
# org.owasp.esapi.errors.ValidationException.actions=log,logout
# sessions jumping between hosts indicates session hijacking
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.count=2
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.interval=10
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.actions=log,logout
#===========================================================================
# ESAPI Validation
#
# The ESAPI validator does many security checks on input, such as canonicalization
# and whitelist validation. Note that all of these validation rules are applied *after*
# canonicalization. Double-encoded characters (even with different encodings involved,
# are never allowed.
#
# To use:
#
# First set up a pattern below. You can choose any name you want, prefixed by the word
# "Validation." For example:
# Validation.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$
#
# Then you can validate in your code against the pattern like this:
# Validator.getInstance().getValidDataFromBrowser( "Email", input );
# Validator.getInstance().isValidDataFromBrowser( "Email", input );
#
Validator.SafeString=^[\p{L}\p{N}.]{0,1024}$
Validator.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$
Validator.IPAddress=^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$
Validator.URL=^(ht|f)tp(s?)\\:\\/\\/[0-9a-zA-Z]([-.\\w]*[0-9a-zA-Z])*(:(0-9)*)*(\\/?)([a-zA-Z0-9\\-\\.\\?\\,\\:\\'\\/\\\\\\+=&%\\$#_]*)?$
Validator.CreditCard=^(\\d{4}[- ]?){3}\\d{4}$
Validator.SSN=^(?!000)([0-6]\\d{2}|7([0-6]\\d|7[012]))([ -]?)(?!00)\\d\\d\\3(?!0000)\\d{4}$
# Validators used by ESAPI
Validator.AccountName=^[a-zA-Z0-9]{3,20}$
Validator.SystemCommand=^[a-zA-Z\\-\\/]{0,64}$
Validator.RoleName=^[a-z]{1,20}$
Validator.Redirect=^\\/test.*$
# Global HTTP Validation Rules
# Values with Base64 encoded data (e.g. encrypted state) will need at least [a-zA-Z0-9\/+=]
Validator.HTTPScheme=^(http|https)$
Validator.HTTPServerName=^[a-zA-Z0-9_.\\-]*$
Validator.HTTPParameterName=^[a-zA-Z0-9_]{0,32}$
Validator.HTTPParameterValue=^[a-zA-Z0-9.\\-\\/+=_ ]*$
Validator.HTTPCookieName=^[a-zA-Z0-9\\-_]{0,32}$
Validator.HTTPCookieValue=^[a-zA-Z0-9\\-\\/+=_ ]*$
Validator.HTTPHeaderName=^[a-zA-Z0-9\\-_]{0,32}$
Validator.HTTPHeaderValue=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$
Validator.HTTPContextPath=^[a-zA-Z0-9.\\-_]*$
Validator.HTTPPath=^[a-zA-Z0-9.\\-_]*$
Validator.HTTPQueryString=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ](1,50)$
Validator.HTTPURI=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$
Validator.HTTPURL=^.*$
Validator.HTTPJSESSIONID=^[A-Z0-9]{10,30}$
# Validation of file related input
Validator.FileName=^[a-zA-Z0-9!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{0,255}$
Validator.DirectoryName=^[a-zA-Z0-9:\\\\!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{0,255}$
Wednesday, June 17, 2009
OWASP Podcast #26 - April News part 2
I just pushed OWASP Podcast #26 live. We had Tom Brennan (White Hat Security), Alex Smolen (Foundstone), Jeff Williams (Aspect) and Andre Gironda (The "House" of AppSec) on the show - a very mixed group with different perspectives.
PS : We discussed the following articles:
- 4/16 http://www.informit.com/articles/article.aspx?p=1338343
- http://www.cigital.com/justiceleague/2009/04/16/software-security-2008/ Gary McGraw uses statistics to show that Software (Application) Security has come of age
- 4/17 http://research.zscaler.com/2009/04/we-used-to-laugh-at-xss.html
- Michael Sutton discusses history of XSS from Defcon 10 (2002) to the present day (Twitter worm)
- 4/17 http://jeremiahgrossman.blogspot.com/2009/04/software-security-grew-to-nearly-500m.html
- Jeremiah uses McDonalds and Mortons as comparatives for black-box vs. white-box security testing
- 4/17 http://jeremiahgrossman.blogspot.com/2009/04/website-threats-and-their-capabilities.html
- OWASP Catalyst announced
- 4/20 http://paco.to/?p=305
- Paco lists 5 reasons for software certifications
- 4/20 http://labs.securitycompass.com/index.php/2009/04/20/security-analysis-of-core-j2ee-design-patterns/
- Rohit Sethi of SecurityCompass posts a blog post on a new Security Compass Labs blog about "Security Analysis of Core Java Enterprise Patterns"
- 4/21 http://docs.google.com/Doc?id=dd7x5smw_16hdd34ggz
- mario heiderich posts some results of browser fuzzing on extraneous characters in tags
- 4/22 http://plynt.com/blog/2009/04/how-frequently-should-an-appli/
- The Plynt blog asks the question, "How frequently shoud Applications be Tested?"
- 4/24 http://www.troopers09.org/content/e3/e445/index_eng.html
- Wendel Guglielmetti Henrique from Trustwave and Sandro Gauchi of EnableSecurity spoke at TROOPERS09 in Munch about "The Truth of Web Application Firewalls: what the vendors do NOT want you to know"
- 4/27 http://tacticalwebappsec.blogspot.com/2009/04/scanner-and-waf-data-sharing.html
- Ryan Barnett gives guidance on how best to make VA+WAF work together
- 4/27 http://www.owasp.org/index.php/Category:OWASP_PCI_Project
- Ed Bellis and Trey Ford start a PCI effort to ensure their activities uniformly meet PCI requirements, and for those getting started - to aid in building a website security strategy that also ensures sustainable PCI compliance.
Friday, June 12, 2009
OWASP Podcast #24 - April News part 1
OWASP Podcast #24 - Part 1 of the OWASP Newscast for April 2009 - is now live!
OWASP Podcast #24 features Alex Smolen, Andre Gironda and Jeff Williams. Andre did all of the extensive copy editor work. We cover a variety of Web App Sec articles found here. The show lasts about 40 minutes.
To listen to OWASP Podcast #24 you can download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes!
OWASP Podcast #24 features Alex Smolen, Andre Gironda and Jeff Williams. Andre did all of the extensive copy editor work. We cover a variety of Web App Sec articles found here. The show lasts about 40 minutes.
To listen to OWASP Podcast #24 you can download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes!
Monday, June 8, 2009
Has WHS jumped the shark?
Does the "WhiteHat Website Security Certification Program" demonstrate that WHS has jumped the proverbial shark?
25% or more of WHS's customers demanded a logo program of this nature, says Jeremiah Grossman, CTO of WHS. Customer demand is not something to ignore lightly.
By the same token, website logo programs of this nature have a dubious past, at best.
Take McAfee's "Hack Safe" program as an obvious example. The level of negative press that the "Hacker Safe" program has generated to date is outstanding.
McAfee 'Hacker Safe' cert sheds more cred. Rubber stamp factory exposed
http://www.theregister.co.uk/2008/04/29/mcafee_hacker_safe_sites_vulnerable/
More bad news for McAfee, HackerSafe certification
http://blogs.zdnet.com/security/?p=1068
Hackersafe? Not so much.
http://holisticinfosec.org/video/HS_ISSA/ISSA_Regional_HackerSafe.html
Russ McGee had a very interesting blog post that was favorable to WHS's new website cert program.
http://holisticinfosec.blogspot.com/2009/05/whitehats-trustmark-program-as-game.html. In the comment section, Jeremiah states:
I think it's also fair to say that what we're offering is more of a "Trust mark" than "Security mark." We do not want lay claim as to the implied security of a website, or the lack thereof. Doing so is a very slippery slope. If our mark does that it is not our intent and we are open to ideas on how best to clarify its true meaning.
To answer your question, only Sentinel customers may display our mark -- which does not come cheaply as compared to others. Organizations who use the Sentinel Service are those who really care about security and the mark should represent that.
and http://www.whitehatsec.com/home/services/certified.html states:
The “website security by WhiteHat Security” mark allows Sentinel subscribers to assure their site visitors that the WhiteHat Sentinel Services is being actively deployed to safeguard confidential data from security breaches and hacker attacks
Jeremiah was faced with a rather difficult choice : upset his customer, or upset some in the security community.
But I must call this a "security fail" for for time being.
a) This cert is not claiming that the website is secure
b) This cert claims that Whitehat Security is the web security service provider, only
c) This cert is consumer based; it's meant for the consumer not the security pro
d) A security-ignorant consumer (the masses) will incorrectly conclude that the website IS secure based on seeing the WHS certification logo, even thou WHS is not making that claim
I think it's also fair to say that what we're offering is more of a "Trust mark" than "Security mark." We do not want lay claim as to the implied security of a website, or the lack thereof. Doing so is a very slippery slope. If our mark does that it is not our intent and we are open to ideas on how best to clarify its true meaning.
To answer your question, only Sentinel customers may display our mark -- which does not come cheaply as compared to others. Organizations who use the Sentinel Service are those who really care about security and the mark should represent that.
and http://www.whitehatsec.com/home/services/certified.html states:
The “website security by WhiteHat Security” mark allows Sentinel subscribers to assure their site visitors that the WhiteHat Sentinel Services is being actively deployed to safeguard confidential data from security breaches and hacker attacks
Jeremiah was faced with a rather difficult choice : upset his customer, or upset some in the security community.
But I must call this a "security fail" for for time being.
a) This cert is not claiming that the website is secure
b) This cert claims that Whitehat Security is the web security service provider, only
c) This cert is consumer based; it's meant for the consumer not the security pro
d) A security-ignorant consumer (the masses) will incorrectly conclude that the website IS secure based on seeing the WHS certification logo, even thou WHS is not making that claim
http://manicode.blogspot.com/2009/06/owasp-asvs-release-version-published.html
PS: So in a few years, when we have a "Aspect Assured" logo, please give me a hard time. :)
OWASP ASVS Release Version published
Application Security Verification Standards are specifications produced by OWASP in cooperation with secure applications developers and verifiers worldwide for the purpose of accelerating the deployment of secure Web applications. First published in 2008 as a result of an OWASP Summer of Code grant and meetings with a small group of early adopters, the ASVS documents have become widely referenced and implemented. Further development of ASVS occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. You can download it here (http://www.owasp.org/index.php/ASVS).
For more information, please contact us. Mike Boberski, Jeff Williams, and Dave Wichers are the primary authors.
Monday, June 1, 2009
OWASP Podcast #23 - Dr. Boaz Gelbord
OWASP Podcast #23, an interview with Dr. Boaz Gelbord - is now live! http://www.owasp.org/download/jmanico/owasp_podcast_23.mp3
Boaz is the co-author of the OWASP Security Spending Benchmarks Project.
Boaz is the co-author of the OWASP Security Spending Benchmarks Project.
iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
Tuesday, May 26, 2009
'Sound' Analysis by Dave Wichers
( This blog post was authored by dave.wichers@aspectsecurity.com )
I recently attended the NSA High Confidence Software & Systems (HCSS) Conference and noticed that many tool vendors and researchers working on static and dynamic analysis were using a new term called sound analysis, which means, ‘no false negatives’. In other words, a ‘sound’ analysis won’t miss any of the types of flaws it is looking for. It might have some false positives.
Bill Scherlis, one of the speakers, defined this as: “In a sound analysis, as distinct from heuristic analysis, we do not produce false negatives. If there is a defect of a particular variety, our sound analysis will find it. I’ll note that a sound analysis may have false positives. The mathematics generally preclude the possibility of having it both ways. But in practice we don’t get many false positives. But the main point is to avoid false negatives, to not miss a diagnosis. We may occasionally over-diagnose but we will never miss a diagnosis.”
I like the idea of this, but I have never heard any of the vendors in our space claim sound analysis for anything they look for. I did see one vendor there that claimed they could provide sound analysis for buffer overflows. The company was Kestrel Technology. They define soundness as: http://www.kestreltechnology.com/about/sound.php
So, if you hear of any code scanning vendor claim they provide ‘sound’ analysis, I’d be interested in hearing about it. dave.wichers@aspectsecurity.com
- Dave Wichers
PS: Because Kestrel does ‘sound’ analysis, they are able to report the kinds of positive information I would love to see from a tool. In my presentation, I had the following security facts label (updated based on Jeff’s original idea 5+ years ago). Imagine tools in our space reporting what I have listed in gray … Wouldn’t that be nice :-)
PPS: I don’t think this is an attack ‘against’ the tools. I think there are two points here:
1) Sound analysis vs. best we can do with current state of the art (and even sound analysis can improve with less false positives).
2) And separately, tools reporting what they have found that’s good, rather just what is bad. However, if tools aren’t doing ‘sound’ analysis, they will be reluctant to report goodness, since they can’t find/report everything that’s relevant (and are thus unsound) :)
I recently attended the NSA High Confidence Software & Systems (HCSS) Conference and noticed that many tool vendors and researchers working on static and dynamic analysis were using a new term called sound analysis, which means, ‘no false negatives’. In other words, a ‘sound’ analysis won’t miss any of the types of flaws it is looking for. It might have some false positives.
Bill Scherlis, one of the speakers, defined this as: “In a sound analysis, as distinct from heuristic analysis, we do not produce false negatives. If there is a defect of a particular variety, our sound analysis will find it. I’ll note that a sound analysis may have false positives. The mathematics generally preclude the possibility of having it both ways. But in practice we don’t get many false positives. But the main point is to avoid false negatives, to not miss a diagnosis. We may occasionally over-diagnose but we will never miss a diagnosis.”
I like the idea of this, but I have never heard any of the vendors in our space claim sound analysis for anything they look for. I did see one vendor there that claimed they could provide sound analysis for buffer overflows. The company was Kestrel Technology. They define soundness as: http://www.kestreltechnology.com/about/sound.php
So, if you hear of any code scanning vendor claim they provide ‘sound’ analysis, I’d be interested in hearing about it. dave.wichers@aspectsecurity.com
- Dave Wichers
PS: Because Kestrel does ‘sound’ analysis, they are able to report the kinds of positive information I would love to see from a tool. In my presentation, I had the following security facts label (updated based on Jeff’s original idea 5+ years ago). Imagine tools in our space reporting what I have listed in gray … Wouldn’t that be nice :-)
PPS: I don’t think this is an attack ‘against’ the tools. I think there are two points here:
1) Sound analysis vs. best we can do with current state of the art (and even sound analysis can improve with less false positives).
2) And separately, tools reporting what they have found that’s good, rather just what is bad. However, if tools aren’t doing ‘sound’ analysis, they will be reluctant to report goodness, since they can’t find/report everything that’s relevant (and are thus unsound) :)
Subscribe to:
Posts (Atom)