OWASP - User contributions [en]

Talk:Securing tomcat

2014-08-23T00:38:03Z

Kenneth Kron:

== InvokerServlet ==
There needs to be an addendum in here about disabling the InvokerServlet. See my blog entry at [[http://yet-another-dev.blogspot.com/2009/12/this-post-is-especially-for-anyone.html yet-another-dev.blogspot.com]] for details about why this is a bad idea. --[[User:Chris Schmidt|Chris Schmidt]] 22:03, 17 December 2009 (UTC)

== File permissions ==

Hmm, what does "Make sure tomcat user has read/write access to /tmp" mean?

Tomcat creates a directory "temp", not "tmp", and read/write on a directory doesn't actually allow reading or writing. I assume the intention is "chmod 700 temp"... would love if anyone can clarify.
[[User:Douglasheld|Douglasheld]] 18:06, 3 April 2009 (UTC)

== Newer Tomcat branches ==

This page is hopelessly outdated for anyone working with the Tomcat 6 branch. We need to figure out the best way to document security measures for the different supported branches.
[[User:Ken|Ken]] 10:25, 20 March 2009 (UTC)

I've not had call to use Tomcat 6, but in a few months I plan to start experimenting with the embedded version. I don't mind expanding the article to have a section on 6 (and keep the section on 5.5), but I can't contribute anything just yet. My preference would be a single article as it will cut down on duplication. In the meantime, any differences, areas to cover, new features, etc. that others could note down will help speed things up. [[User:Dledmonds|Darren]] 09:11, 26 March 2009 (UTC)

== HttpOnly configuration ==

Tomcat versions from 5.5.28 and 6.0.19 support the HttpOnly [http://www.owasp.org/index.php/HttpOnly] cookie option.

This is configured in the conf/context.xml file:

<Context useHttpOnly="true">
...
</Context>

[[User:Simon Bennetts|Simon Bennetts]] 14:40, 18 June 2010 (UTC)

== Overriding Tomcat Version Number ==

Rebuilding the catalina.jar to alter ServerInfo.properties may not be an ideal way to override the version number, the same effect can be achieved without repackaging JARs in the default distribution (repackaging can be somewhat intrusive and/or impractical). Classloader classpaths can be patched using strategically placed files on the classpath. Classes that are loaded first always take precedence, the same goes for properties files, hence you can override by creating files in the following places:

# For Tomcat 5.5 (inject your new file onto the path of the server classloader):
${catalina.home}/server/classes/org/apache/catalina/util/ServerInfo.properties

# For Tomcat 6 (inject it onto the path of the common classloader, or whichever classloader is loading catalina.jar):
${catalina.home}/lib/org/apache/catalina/util/ServerInfo.properties

In both cases, ${catalina.home} is typically either the root of your local installation, or your global installation if you are making use of disjoint installs using ${catalina.base} to provide instance-specific information.

== autoDeploy feature ==

Wouldn't it make sense to disable the autoDeploy feature in production environments for added security?

[[User:Pierre Ernst|Pierre Ernst]] 2011-08-12

== Disabling weak ciphers in Tomcat ==

Copied from [https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1225]

In order to disable weak ciphers, please modify your SSL Connector container attribute inside server.xml with the following information.

ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"

Example:

<Connector port="443" maxHttpHeaderSize="8192" address="192.168.1.1"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="SSL"
ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
keystoreFile="SomeDir/SomeFile.key" keystorePass="Poodle"
truststoreFile="SomeDir/SomeFile.truststore" truststorePass="HomeRun"/>

[[User:Psiinon]] 2011-10-06

[[User:Dirk Wetter]] 2014-03-27 : Those ciphers were maybe ok in 2011, in 2014 I would not recommend using RC4 and CBC ciphers!

== No missing steps required in Tomcat 7 or 8 ==
I've done some research and as far as I can tell there are no recommended hardening steps for Tomcat 7 or 8 missing from this guide.

http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Securing_Management_Applications
http://chandank.com/application-server/tomcat/apache-tomcat-hardening-and-security-guide

The SSL Cipher list should be upgraded however:
http://www.sslshopper.com/article-how-to-disable-weak-ciphers-and-ssl-2-in-tomcat.html

[[User:Kenneth Kron|Kenneth Kron]] ([[User talk:Kenneth Kron|talk]]) 16:56, 22 August 2014 (CDT)

Talk:Securing tomcat

2014-08-22T21:56:48Z

Kenneth Kron:

== InvokerServlet ==
There needs to be an addendum in here about disabling the InvokerServlet. See my blog entry at [[http://yet-another-dev.blogspot.com/2009/12/this-post-is-especially-for-anyone.html yet-another-dev.blogspot.com]] for details about why this is a bad idea. --[[User:Chris Schmidt|Chris Schmidt]] 22:03, 17 December 2009 (UTC)

== File permissions ==

Hmm, what does "Make sure tomcat user has read/write access to /tmp" mean?

Tomcat creates a directory "temp", not "tmp", and read/write on a directory doesn't actually allow reading or writing. I assume the intention is "chmod 700 temp"... would love if anyone can clarify.
[[User:Douglasheld|Douglasheld]] 18:06, 3 April 2009 (UTC)

== Newer Tomcat branches ==

This page is hopelessly outdated for anyone working with the Tomcat 6 branch. We need to figure out the best way to document security measures for the different supported branches.
[[User:Ken|Ken]] 10:25, 20 March 2009 (UTC)

I've not had call to use Tomcat 6, but in a few months I plan to start experimenting with the embedded version. I don't mind expanding the article to have a section on 6 (and keep the section on 5.5), but I can't contribute anything just yet. My preference would be a single article as it will cut down on duplication. In the meantime, any differences, areas to cover, new features, etc. that others could note down will help speed things up. [[User:Dledmonds|Darren]] 09:11, 26 March 2009 (UTC)

== HttpOnly configuration ==

Tomcat versions from 5.5.28 and 6.0.19 support the HttpOnly [http://www.owasp.org/index.php/HttpOnly] cookie option.

This is configured in the conf/context.xml file:

<Context useHttpOnly="true">
...
</Context>

[[User:Simon Bennetts|Simon Bennetts]] 14:40, 18 June 2010 (UTC)

== Overriding Tomcat Version Number ==

Rebuilding the catalina.jar to alter ServerInfo.properties may not be an ideal way to override the version number, the same effect can be achieved without repackaging JARs in the default distribution (repackaging can be somewhat intrusive and/or impractical). Classloader classpaths can be patched using strategically placed files on the classpath. Classes that are loaded first always take precedence, the same goes for properties files, hence you can override by creating files in the following places:

# For Tomcat 5.5 (inject your new file onto the path of the server classloader):
${catalina.home}/server/classes/org/apache/catalina/util/ServerInfo.properties

# For Tomcat 6 (inject it onto the path of the common classloader, or whichever classloader is loading catalina.jar):
${catalina.home}/lib/org/apache/catalina/util/ServerInfo.properties

In both cases, ${catalina.home} is typically either the root of your local installation, or your global installation if you are making use of disjoint installs using ${catalina.base} to provide instance-specific information.

== autoDeploy feature ==

Wouldn't it make sense to disable the autoDeploy feature in production environments for added security?

[[User:Pierre Ernst|Pierre Ernst]] 2011-08-12

== Disabling weak ciphers in Tomcat ==

Copied from [https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1225]

In order to disable weak ciphers, please modify your SSL Connector container attribute inside server.xml with the following information.

ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"

Example:

<Connector port="443" maxHttpHeaderSize="8192" address="192.168.1.1"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="SSL"
ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
keystoreFile="SomeDir/SomeFile.key" keystorePass="Poodle"
truststoreFile="SomeDir/SomeFile.truststore" truststorePass="HomeRun"/>

[[User:Psiinon]] 2011-10-06

[[User:Dirk Wetter]] 2014-03-27 : Those ciphers were maybe ok in 2011, in 2014 I would not recommend using RC4 and CBC ciphers!

== No missing steps required in Tomcat 7 or 8 ==
I've done some research and as far as I can tell there are no recommended hardening steps for Tomcat 7 or 8 missing from this guide.

http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Securing_Management_Applications
http://chandank.com/application-server/tomcat/apache-tomcat-hardening-and-security-guide

[[User:Kenneth Kron|Kenneth Kron]] ([[User talk:Kenneth Kron|talk]]) 16:56, 22 August 2014 (CDT)

Talk:Injection Theory

2013-05-23T19:26:55Z

Kenneth Kron: Created page with "I was suprised to find the wikipedia definition of data flow to be substanially different than the one I commonly hear used in programming circles. Data Flow: (See [ http:..."

I was suprised to find the wikipedia definition of data flow to be substanially different than the one I commonly hear used in programming circles.

Data Flow:

(See [ http://en.wikipedia.org/wiki/Message_passing Wikipedia message passing]

"Message passing is the paradigm of communication where messages are sent from a sender to one or more recipients. Forms of messages include (remote) method invocation, signals, and data packets. When designing a message passing system several choices are made:"

So from the above definition.

Modern web based programming tends to take a lazy approach to messaging in that the raw message is generally passed from the http layer as far as possible. In part this is because different parts of the application act on different messages and in order to maintain the stateless communication model of the web each message must contain enough context to complete the entire transaction.

Java Server Faces

2013-05-23T17:53:31Z

Kenneth Kron:

==Status==
Under review 10/3/2008

==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement its own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not trust request parameter
* Do not trust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.

==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.html

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find more info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a continuous sync between the dom sent to the browser and a dom representation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick locking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is up to the application designer to implement a robust security logic behind the scenes.
In another point of view the developer could focus on implementing server side security since with the server-side-dom architecture the thin client is even thinner.

The component that refresh the two dom , called IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:OWASP Java Project]]

Java Server Faces

2013-05-23T17:50:15Z

Kenneth Kron:

==Status==
Under review 10/3/2008

==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement its own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not trust request parameter
* Do not trust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.

==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.html

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find more info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a coninus sync between the dom sent to the browser and a dom representation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick locking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is all ups to the application designer to implement a robust security logic behind the scenes.
In another point of view the developer could focus on implementing server side security since with the server-side-dom architecture the thin client is even thinner.

The component that refresh the two dom , caled IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:OWASP Java Project]]

File:Threat Graph.gif

2009-09-04T14:17:58Z

Kenneth Kron: uploaded a new version of "File:Threat Graph.gif": Reverted to version as of 13:50, 4 September 2009

File:Threat Graph.gif

2009-09-04T13:53:22Z

Kenneth Kron: uploaded a new version of "File:Threat Graph.gif": Really I made the change!

File:Threat Graph.gif

2009-09-04T13:50:13Z

Kenneth Kron: uploaded a new version of "File:Threat Graph.gif": 

File:Threat Graph.gif

2009-09-04T13:47:59Z

Kenneth Kron: uploaded a new version of "File:Threat Graph.gif": mail fail -> may fail

Threat Risk Modeling

2009-09-04T13:33:27Z

Kenneth Kron: /* Identify Threats */

__TOC__

When you start a web application design, it is essential to apply threat risk modeling; otherwise you will squander resources, time, and money on useless controls that fail to focus on the real risks.

The method used to assess risk is not nearly as important as actually performing a structured threat risk modeling. Microsoft notes that the single most important factor in their security improvement program was the corporate adoption of threat risk modeling.

OWASP recommends Microsoft’s threat modeling process because it works well for addressing the unique challenges facing web application security and is simple to learn and adopt by designers, developers, code reviewers, and the quality assurance team.

The following sections provide some overview information (or see Section 6.9, Further Reading, for additional resources).

== Threat Risk Modeling ==
Threat risk modeling is an essential process for secure web application development. It allows organizations to determine the correct controls and to produce effective countermeasures within budget. For example, there is little point in spending $100,000 for fraud control for a system that has negligible fraud risk.

== Performing threat risk modeling using the Microsoft Threat Modeling Process ==
The threat risk modeling process has five steps, enumerated below and shown graphically in Figure 1. They are:
# Identify Security Objectives
# Survey the Application
# Decompose it
# Identify Threats
# Identify Vulnerabilities

[[Image:Threat_Model_Flow.gif|Figure 1: Threat Model Flow]]

Let’s consider the steps in more detail.

=== Identify Security Objectives ===
The business (or project management) leadership, in concert with the software development and quality assurance teams, all need to understand the security objectives. To facilitate this, start by breaking down the application’s security objectives into the following categories:

* '''Identity:''' Does the application protect user identity from abuse? Are there adequate controls in place to ensure evidence of identity (as required for many banking applications?)
* '''Financial:''' Assess the level of risk the organization is prepared to absorb in remediation, as a potential financial loss. For example, forum software may have a lower estimated financial risk than an Internet banking application.
* '''Reputation:''' Quantify or estimate of the loss of reputation derived from the application being misused or successfully attacked.
* '''Privacy and Regulatory:''' To what extent will the application have to protect user data? Forum software by its nature is public, but a tax preparation application is subject to tax regulations and privacy legislation requirements in most countries.
* '''Availability Guarantees:''' Is the application required to be available per a '''''Service Level Agreement (SLA)''''' or similar guarantee? Is it a nationally protected infrastructure? To what level will the application have to be available? High availability techniques are significantly more expensive, so applying the correct controls up front will save a great deal of time, resources, and money.

This is by no means an exhaustive list, but it gives an idea of some of the business risk decisions leading into selecting and building security controls.

Other sources of risk guidance come from:
* Laws (such as privacy or finance laws)
* Regulations (such as banking or e-commerce regulations)
* Standards (such as ISO 17799)
* Legal Agreements (such as payment card industry standards or merchant agreements)
* Corporate Information Security Policy

=== Application Overview ===
Once the security objectives have been defined, analyze the application design to identify the '''''components''''', '''''data flows''''', and '''''trust boundaries'''''.

Do this by surveying the application’s architecture and design documentation. In particular, look for UML component diagrams. Such high level component diagrams are generally sufficient to understand how and why data flows to various places. For example, data movement across a trust boundary (such as from the Internet to the web tier, or from the business logic to the database server), needs to be carefully analyzed, whereas data that flows within the same trust level does not need as much scrutiny.

=== Decompose Application ===
Once the application architecture is understood then decompose it further, to identify the features and modules with a security impact that need to be evaluated. For example, when investigating the authentication module, it is necessary to understand how data enters the module, how the module validates and processes the data, where the data flows, how the data is stored, and what fundamental decisions and assumptions are made by the module.

=== Identify Threats ===
It is impossible to write down unknown threats, but it is likewise unlikely that new malware will be created to exploit new vulnerabilities within custom systems. Therefore, concentrate on known risks, which can be easily demonstrated using tools or techniques from Bugtraq.

Microsoft suggests two different approaches for writing up threats. One is a threat graph, as shown in Figure 2, and the other is a structured list. 
[[Category:FIXME|Change 3rd orange box in graphic to "Authorization MAY fail"]]

[[Image:Threat_Graph.gif|Figure 2: Threat Graph]]

Typically, a threat graph imparts more information quickly but it takes longer to construct, while a structured list is easier to create but it will take longer for the threat impacts to become obvious.

# Attacker may be able to read other user’s messages
# User may not have logged off on a shared PC
# Data validation may allow SQL injection
# Implement data validation
# Authorization may fail, allowing unauthorized access
# Implement authorization checks
# Browser cache may contain contents of message
# Implement anti-caching directive in HTTP headers
# If eavesdropping risk is high, use SSL

Note that it takes a motivated attacker to exploit a threat; they generally want something from your application or to obviate controls. To understand the relevant threats, use the following categories to understand who might attack the application:

* '''Accidental Discovery:''' An ordinary user stumbles across a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality.
* '''Automated Malware:''' Programs or scripts, which are searching for known vulnerabilities, and then report them back to a central collection site.
* '''The Curious Attacker:''' a security researcher or ordinary user, who notices something wrong with the application, and decides to pursue further.
* '''Script Kiddies:''' Common renegades, seeking to compromise or deface applications for collateral gain, notoriety, or a political agenda, perhaps using the attack categories described in the ''OWASP Web Application Penetration Checklist.''
* '''The Motivated Attacker:''' Potentially, a disgruntled staff member with inside knowledge or a paid professional attacker.
* '''Organized Crime:''' Criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

It is vital to understand the level of attacker you are defending against. For example, a motivated attacker, who understands your internal processes is often more dangerous than script kiddies.

=== STRIDE ===
STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the attacker). The STRIDE acronym is formed from the first letter of each of the following categories.

'''''Spoofing Identity'''''
“Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the application and database level. In particular, users should not be able to become any other user or assume the attributes of another user.

'''''Tampering with Data'''''
Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, which are obtainable only from within the application itself. The application should also carefully check data received from the user and validate that it is sane and applicable before storing or using it.

'''''Repudiation'''''
Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, “But I didn’t transfer any money to this external account!”, and you cannot track his/her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user’s privileges, not more, but this may not be possible with many off-the-shelf application frameworks.

'''''Information Disclosure'''''
Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also, consider if the user’s web browser may leak information. Some web browsers may ignore the no caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser, just in case it leaks or leaves information behind, which can be used by an attacker to learn details about the application, the user, or to potentially become that user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should not be relied on to secure sensitive information or to provide adequate personal privacy safeguards.

'''''Denial of Service'''''
Application designers should be aware that their applications may be subject to a denial of service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users, and not available to anonymous users.

For applications that do not have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, to avoid exposing large files or unique links per user, in order to prevent simple denial of service attacks.

'''''Elevation of Privilege'''''
If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one. In particular, simply not displaying privileged role links is insufficient. Instead, all actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality.

=== DREAD ===
DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.

DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.

'''Risk_DREAD''' = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk.

Here are some examples of how to quantify the DREAD categories.

'''''Damage Potential'''''
* If a threat exploit occurs, how much damage will be caused?
**0 = Nothing
**5 = Individual user data is compromised or affected.
**10 = Complete system or data destruction

'''''Reproducibility'''''
* How easy is it to reproduce the threat exploit?
**0 = Very hard or impossible, even for administrators of the application.
**5 = One or two steps required, may need to be an authorized user.
**10 = Just a web browser and the address bar is sufficient, without authentication.

'''''Exploitability'''''
* What is needed to exploit this threat?
**0 = Advanced programming and networking knowledge, with custom or advanced attack tools.
**5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.
**10 = Just a web browser

'''''Affected Users'''''
* How many users will be affected?
**0 = None
**5 = Some users, but not all
**10 = All users

'''''Discoverability'''''
* How easy is it to discover this threat?
**0 = Very hard to impossible; requires source code or administrative access.
**5 = Can figure it out by guessing or by monitoring network traces.
**9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
**10 = The information is visible in the web browser address bar or in a form.

'''Note:''' When performing a security review of an existing application, “Discoverability” will often be set to 10 by convention, as it is assumed the threat issues will be discovered.

'''Note:''' Using DREAD can be difficult at first. It may be helpful to think of Damage Potential and Affected Users in terms of Impact, while thinking of Reproducibility, Exploitability, and Discoverability in terms of Probability. Using the Impact vs Probability approach (which follows best practices such as defined in NIST-800-30), I would alter the formula to make the Impact score equal to the Probability score. Otherwise the probability scores have more weight in the total.

== Alternative Threat Modeling Systems ==
OWASP recognizes that the adoption of the Microsoft modeling process may not fit all organizations. If STRIDE and DREAD are unacceptable for some reason, we recommend that your organization “dry run” the other threat risk models discussed against an existing application or design. This will allow you to determine which approach works best for you, and to adopt the most appropriate threat modeling tools for your organization.

'''In summary, performing threat modeling provides a far greater return than most any other control in this Guide. Therefore, make threat risk modeling an early priority in your application design process.'''

=== Trike ===
Trike is a threat modeling framework with similarities to the Microsoft threat modeling processes. However, Trike differs because it uses a risk based approach with distinct implementation, threat, and risk models, instead of using the STRIDE/DREAD aggregated threat model (attacks, threats, and weaknesses).
From the Trike paper, Trike’s goals are:
* With assistance from the system stakeholders, to ensure that the risk this system entails to each asset is acceptable to all stakeholders.
* Be able to tell whether we have done this.
* Communicate what we’ve done and its effects to the stakeholders.
* Empower stakeholders to understand and reduce the risks to them and other stakeholders implied by their actions within their domains.

For more information on Trike, please see Section 6.9, reference 8.

=== AS/NZS 4360:2004 Risk Management ===
The Australian/New Zealand Standard AS/NZS 4360, first issued in 1999, and revised in 2004, is the world’s first formal standard for documenting and managing risk and is still one of the few formal standards for managing it.
The standard’s approach is simple (it’s only 28 pages long), flexible, and iterative. Furthermore, it does not lock organizations into a particular risk management methodology, provided the methodology fulfils the AS/NZS 4360 five steps. It also provides several sets of risk tables as examples, and allows organizations to freely develop and adopt their own.

'''The five steps of the AS/NZS 4360 process are:'''
* '''Establish Context:''' Establish the risk domain, i.e., which assets/systems are important?
* '''Identify the Risks:''' Within the risk domain, what specific risks are apparent?
* '''Analyze the Risks:''' Look at the risks and determine if there are any supporting controls in place.
* '''Evaluate the Risks:''' Determine the residual risk.
* '''Treat the Risks:''' Describe the method to treat the risks so that risks selected by the business will be mitigated.
AS/NZS 4360 assumes that risk will be managed by an '''''operational risk group''''', and that the organization has adequate skills and risk management resources in house to identify, analyze, and treat the risks.

'''The advantages of AS/NZS 4360:'''
* AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.
* AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as just using likelihood and consequence to determine an overall risk.
* AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS/NZS 4360 compatible approach.
* You are an Australian organization, and may be required to use it if you are audited on a regular basis, or to justify why you aren’t using it. Luckily, the STRIDE/DREAD model discussed earlier is AS/NZS 4360 compatible.

'''The limitations of AS/NZS 4360:'''
* The AS/NZS 4360 approach works best for business or systemic risks than for technical risks.
* AS/NZS 4360 does not define the methodology to perform a structured threat risk modeling exercise.
* As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.
Although AS/NZS 4360 may be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methodologies described earlier.

=== CVSS ===
The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco Systems, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the group’s outputs is the '''''Common Vulnerability Scoring System (CVSS).'''''

'''The advantages of CVSS:'''
* You have just received notification from a security researcher or other source that your product has vulnerability, and you wish to ensure that it has an accurate and normalized severity rating, so as to alert your customers to the appropriate level of action required when you release the patch.
* You are a security researcher, and have found several threat exploits within an application. You would like to use the CVSS ranking system to produce reliable risk rankings, to ensure that the ISV will take the exploits seriously as indicated by their rating.
* CVSS has been recommended by the working group for use by US Government departments. However, it is unclear if it will become policy or be widely adopted at the time of this writing.
[[Category:FIXME|The first two are more scenarios than advantages]]

'''The limitations of CVSS:'''
* CVSS does not find or reduce the attack surface area (i.e. design flaws), or help enumerate risks within any arbitrary piece of code, as it is just a scoring system, not a modeling methodology.
* CVSS is more complex than STRIDE/DREAD, as it aims to calculate the risk of announced vulnerabilities as applied to deployed software and environmental factors.
* The CVSS risk ranking is complex – a spreadsheet is required to calculate the risk components as the assumption behind CVSS is that a specific vulnerability has been identified and announced, or a worm or Trojan has been released targeting a small number of attack vectors.
* The overhead of calculating the CVSS risk ranking is quite high if applied to a thorough code review, which may have 250 or more threats to rank.

=== OCTAVE ===
OCTAVE is a heavyweight risk methodology approach originating from Carnegie Mellon University’s Software Engineering Institute (SEI) in collaboration with CERT. OCTAVE focuses on organizational risk, not technical risk.
OCTAVE comes in two versions: Full OCTAVE, for large organizations, and OCTAVE-S for small organizations, both of which have specific catalogs of practices, profiles, and worksheets to document the modeling outcomes.

'''OCTAVE is popular with many sites and is useful when:'''
* Implementing an organizational culture of risk management and controls becomes necessary.
* Documenting and measuring business risk becomes timely.
* Documenting and measuring the overall IT security risk, particularly as it relates to the corporate IT risk management, becomes necessary.
* When documenting risks surrounding complete systems becomes necessary.
* To accommodate a fundamental reorganization, such as when an organization does not have a working risk methodology in place, and requires a robust risk management framework to be put in place.

'''The limitations of OCTAVE are:'''
* OCTAVE is incompatible with AS/NZS 4360, as it mandates Likelihood = 1 (i.e., It assumes a threat will always occur) and this is inappropriate for many organizations. OCTAVE-S makes the inclusion of this probability optional, but this is not part of the more comprehensive OCTAVE standard.
* Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement.
* It does not provide a list of “out of the box” practices for assessing and mitigating web application security risks.

Because of these issues, OWASP does not anticipate that OCTAVE will be used at large by application designers or developers, because it fails to take threat risk modeling into consideration, which is useful during all stages of development, by all participants, to reduce the overall risk of an application becoming vulnerable to attack.

== Conclusion ==
In this chapter, we have touched on the basic principles of threat risk modeling, risk management, and web application security. Applications that leverage the underlying intent of these principles will be more secure than their counterparts, which will only be minimally compliant just by including specific controls.

== Further Reading ==
* [http://www.microsoft.com/downloads/details.aspx?FamilyId=59888078-9DAF-4E96-B7D1-944703479451 Threat Analysis & Modeling v2.1.2], © Microsoft Corporation, 2007. [[category:FIXME |link not working, please replace]]
* [http://msdn.microsoft.com/library/ms978516.aspx Threat Modeling Web Applications], J.D. Meier, Alex Mackman, Blaine Wastell, © Microsoft Corporation, May 2005.
* [http://msdn.microsoft.com/library/ms994921.aspx Improving Web Application Security: Threats and Countermeasures], J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, © Microsoft Corporation, June 2003.
* [http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en Threat Modeling], Frank Swiderski and Window Snyder, Microsoft Press, June 2004, ISBN 0-7356-1991-3.
* Writing Secure Code, 2nd Edition, Howard and LeBlanc, (pp. 69 – 124), Microsoft Press, 2003, ISBN 0-7356-1722-8.
* [http://msdn.microsoft.com/library/ms954176.aspx The STRIDE Threat Model], © Microsoft Corporation, 2005.
* [http://blogs.msdn.com/david_leblanc/archive/2007/08/13/dreadful.aspx DREADful] - the DREAD system, © Microsoft Corporation, 2005.
* [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf A Conceptual Model for Threat Modeling Applications], Saitta, Larcom, and Michael Eddington, July 2005, http://dymaxion.org/trike/.
* [http://www.standards.co.nz/web-shop/?action=viewSearchProduct&mod=catalog&pid=4360:2004(AS|NZS) AS/NZS 4360:2004 Risk Management], Standards Australia and Standards New Zealand.
* [http://www.dhs.gov/interweb/assetlibrary/NIAC_CyberVulnerabilitiesPaper_Feb05.pdf CVSS], U.S. Department of Homeland Security library, February 2005. [[category:FIXME |link not working, please replace]]
* [http://www.cert.org/octave/ OCTAVE], CERT library.

== Appendix: Alternative open-source Risk Management tools ==
* [http://sourceforge.net/projects/osmr/ OSMR]
* [http://sourceforge.net/projects/marco/ MARCO]
* [http://sourceforge.net/projects/coras/ CORAS Risk Assessment Platform]
* [http://sourceforge.net/projects/ratiso17799/ ISO 17799 Risk Assessment Toolkit]
* [http://sourceforge.net/projects/easy-tra/ Easy Threat Risk Assessment]
* [http://sourceforge.net/projects/arms-17799/ ARMS]
* [http://sourceforge.net/projects/minaccia/ Minaccia]
* [http://sourceforge.net/projects/threatmind/ ThreatMind]
* [http://sourceforge.net/projects/osrmt/ Open Source Requirements Management Tool]

== Reference ==
[[Guide Table of Contents|Development Guide Table of Contents]]

[[Category:OWASP_Guide_Project]]
[[Category:Activity]]
[[Category:Externally Linked Page]]