OWASP - User contributions [en]

Hibernate

2015-04-30T15:22:48Z

Jarrod Stenberg: /* Creating, manipulating and executing queries */

== Status ==
'''In progress'''

== Before you begin ==
Since ORM architecture isn't obvious, this document will explain some important things you need to know in order to analyze a Hibernate application in a security context. This document assumes some SQL and database knowledge.

=== A note about SQL injection ===
Since it is the hot topic, I will address it now but discuss in detail later.
* Hibernate does not grant immunity to SQL Injection, one can misuse the api as they please.
* There is nothing special about HQL (Hibernates subset of SQL) that makes it any more or less susceptible.
* Functions such as createQuery(String query) and createSQLQuery(String query) create a Query object that will be executed when the call to commit() is made. If the query string is tainted you have sql injection. The details of these functions are covered later.

== Overview ==

=== The problem Hibernate addresses ===
In object oriented systems, we represent entities as objects, and use a database to persist those objects. Generally these objects are considered non-scalar values (non-primitive types).
But many databases can only store and manipulate scalar values organized in tables.
The crux of the problem is translating those objects to forms which can be stored in the database, and which can later be retrieved easily, while preserving the properties of the objects and their relationships; these objects are then said to be persistent.
Hibernate attempts to address this problem with Object/Relational Mapping (O/R M) by mapping attributes of objects we wish to persist to columns of a database.

[http://en.wikipedia.org/wiki/Object-relational_mapping See original article. ]

=== How it works ===
* Usually Hibernate applications use [http://en.wikipedia.org/wiki/JavaBean JavaBeans] style [http://en.wikipedia.org/wiki/Plain_Old_Java_Object POJOs] to represent objects we want to persist in a database.
* These objects should have an identifier property (i.e private class variable) used to represent it's primary key value in the database.
* This identifier will be mapped in a hibernate mapping file, usually with the default extension .hbm.xml, you will see this mapping in the <id> element. This file will also map all other object properties we wish to preserve to columns in a database table, along with their data types and other stuff.
* Once objects are mapped, Hibernate provides the mechanism for you to store and access them via org.hibernate.Session and org.hibernate.Transaction objects.
* The Session object has methods to save() objects to a session, load() objects from a database and createQuery()s to be executed against the database.
* The Transaction object often wraps a database transaction, allowing one to begin() transactions, commit() changes, and rollback() to a previous state.
* Other classes worth mentioning: SessionFactory, TransactionFactory, and Query.
* Hibernate's main configuration file, extension .cfg.xml, provides basic setup for things like datasource, dialect, mapping files, etc.
[http://www.owasp.org/index.php/Hibernate/config-example See this configuration example]

=== Jargon ===
*'''Transient''' - The instance is not associated with a Session, has no persistent representation in the database and no identifier assigned. An object that has just been instantiated with the new operator is said to be transient.
*'''Persistent''' - Is associated with a Session, has a representation in the database and has been assigned an identifier. Hibernate synchronizes changes on a persistent object with its representation in the database when it completes a unit of work.
*'''Detatched''' - was once in a persistent state, but its session has been closed. The reference is still valid and the object may be modified and even reattached to a new session later.

=== Hitting the database ===
The Session object represents the main interface or ''conversation'' between Java and Hibernate. A Session is used for a single request, or unit of work. To make an object persistent, it must first be associated with a Session. But where does the session come from? Hibernate's Configuration object instantiates a SessionFactory (Configuration.buildSessionFactory()) which is an expensive, immutable, thread safe object intended to be shared by all application threads. Threads that service client requests must obtain a Session from the factory by calling SessionFactory.getCurrentSession() or SessionFactory.openSession().

Anyways, a Session is NOT thread safe and there are associated concurrency issues discussed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Session_and_Concurrency_issues this section] of the Hibernate Guidelines page. Once an object is associated with a Session we can begin a transaction. All database communication must occur within the scope of a transaction. A transaction starts with a call to Transaction.begin() or Session.beginTransaction() and ends with a call to Transaction.commit().

To actually build queries, store and retrieve data we mostly use methods in the Session class. For example, load() will instantiate a class object, and load the state from the database into the instance. Session.createQuery() will return a Query object which has many methods with which to operate on this query string. Query.setParameter(), setFloat(), and others act similar to prepared statements. You can also simply call Query.executeUpdate() to execute the query.

''Ok, why don't we just see what it looks like.''
Example1
<pre>
Session sess = factory.openSession();
Transaction tx;
try {
tx = sess.beginTransaction();
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
tx.commit();
}
catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
finally {
sess.close();
}
</pre>
''Another simple example using HQL and named parameters...this time we have a helper class to obtain a Session''
<pre>
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction(); //All database communication occurs within the scope of a transaction

Person aPerson = (Person) session
.createQuery("select p from Person p left join fetch p.events where p.id = :pid")
.setParameter("pid", personId);

session.getTransaction().commit();
</pre>

== Security Implications ==
These issues are discussed in context on this page and are also listed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Important this section] of Hibernate Guidelines.

* No communication with the database should occur outside of a database transaction. Doing so will probably result in synchronization issues. Transactions should also not encompass user think time. Details are of how it's done is discussed in the [http://www.owasp.org/index.php/Hibernate#Defining_Transaction_Bounds Defining Transaction Bounds section] of this page.

* createQuery() can easily be passed a tainted SQL or HQL string, dialect is irrelevant. The proper way to construct a sql string hibernate style is to use Query and SQLQuery's setParameter(), setString(), setXXX() methods for named parameter and placeholder binding. Just like prepared statements. Details are discussed in the [http://www.owasp.org/index.php/Hibernate#Creating_Queries Creating Queries section] of this page.

* Persisting tainted objects is stored xss. Since stored XSS is generally hard to find with static tools, it is best to sanitize all data going in rather than waiting for it to show up on a jsp somewhere. Details of these functions are discussed in the [http://www.owasp.org/index.php/Hibernate#Persisting_Tainted_Data Persisting Tainted Data section] of this page.

* An application should rollback and discard Session instance on error. So if the Session throws an exception, the catch block should have rollback() and finally should call Session.close(). This applies to any SQLException. Pretty cut and dry, see Example1 above.

* You may not mix and match JDBC-style parameters ("?") and named parameters (:namedparam) in the same query.
<pre>
Person aPerson = (Person) session
.createQuery("select :somenamedparameter from ? where x = :someothernamedparameter");
</pre>
* Transaction.setTimeout(int) should be called to ensure that misbehaving transactions do not tie up resources in definitely.
<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
</pre>

== Defining Transaction Bounds ==
Usually, ending a Session involves four distinct phases:

* flush the session
* commit the transaction
* close the session
* handle exceptions

Note:
* If commit() is present, no need to call flush() as it does this already.
* Most database communication methods only propagate exceptions if they're outside the scope of the session. (this is an assumption based on the many functions whose source I've examined, I won't be perusing the entire api source to back this assumption)

Consider this example:
<pre>
// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>
Most Common Functions:

* Session.beginTransaction() - begin transaction (doh)
* Session.getTransaction() - begin transaction
* Session.flush() - end transaction
* Session.close() - end session
* Transaction.begin() - begin transaction
* Transaction.commit() - end transaction
* Transaction.rollback() -

== Creating, manipulating and executing queries ==
* The Session interface defines methods that create Query and SQLQuery objects - these are the methods we care about because they allow the developer to construct query strings (as opposed to letting Hibernate perform the sql operations).
* The Query/SQLQuery objects are mutable and executable, but are not actually SUNK until Transaction.commit(), or Query.executeUpdate() is called. However, I think it is best that we flag functions that create and construct Query objects as they would be in direct contact with tainted data.
* Once a Query or SQLQuery object is obtained from the Session, the parameters of its sql string should be set using the setter functions like setParameter(), the setters are listed here. These setters check for type mismatch, or guess the type, then check for positional mismatch and named parameter mismatch so they're pretty safe me thinks. Concatenating tainted parameters using the '+' operator, on the other hand, would be equivalent to mis-using a prepared-statement.

Consider this example:
<pre>
String table = (String) req.getParameter("table");//obviously prone to tainted input
String parameter1 = request.getParameter("param1");

Session session = sessionFactory.getCurrentSession();
try{
session.beginTransaction();
SQLQuery query = session.createSQLQuery("SELECT * FROM " + table + "WHERE stuff= ?"); /*B00*/
query.setParameter(0, parameter1); /*YAY*/
session.getTransaction().commit();
} catch (Exception e) {}
session.close();//omfg no rollback?
</pre>
Most Common Functions:

* Session.createSQLQuery(String queryString) - creates a Query with given SQL string - technically executed on commit() or flush() but this function is more directly related to the taint source.
* Session.createQuery(String queryString) - creates Query with given HQL string.
* Session.createFilter(Object collection, String queryString) - creates a Query with filter string.
* Query.setParameter() - variations on this binds parameters to "?" and ":namedparams"
* Query.executeUpdate() -
* Query.getQueryString() -

==== More Examples ====

Using queries from other Queries:
<pre>
String sql;

session.beginTransaction();
Query q1 = session.createQuery(taintSQL); //pretend taintSQL came from unchecked input
sql = q1.getQueryString(); //get taintSQL
session.getTransaction.commit();

session.beginTransaction();
Query q2 = new QueryImpl(sql, session, parameterMetadata); //reuse taintSQL w/o validation
session.getTransaction.commit(); //evil prevails
session.close();
</pre>
Using executeUpdate()
<pre>
public void executeUpdateHQL(Session session, String evil)//a few calls deep from where evil became tainted
{
Query query = session.createQuery(evil); /*B00*/
query.setString("name","Evil");
query.setString("newName","EEvil"); //these don't matter if the sql is already evil
int rowCount = query.executeUpdate(); /*B00*/
System.out.println("Rows affected: " + rowCount);

//See the results of the update and some other random stuff
query = session.createQuery("from Supplier");
List results = query.list();

displaySupplierList(results);
}
</pre>
named parameter (preferred)
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
Iterator cats = q.iterate();
</pre>
positional parameter
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>
named parameter list
<pre>
List names = new ArrayList();
names.add("Izi");
names.add("Fritz");
Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)");
q.setParameterList("namesList", names);
List cats = q.list();
</pre>
Executing a bunch of actions (relevant fns listed in the excel sheet)
<pre>
private List executions;
....
executions = new LinkedList();
....
private void executeActions(List list) throws HibernateException {
for ( Iterator execItr = list.iterator(); execItr.hasNext(); ) {
execute( (Executable) execItr.next() );
}
list.clear();
session.getBatcher().executeBatch();
}
public void execute(Executable executable) {
final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
if (lockQueryCache) {
session.getFactory()
.getUpdateTimestampsCache()
.preinvalidate( executable.getPropertySpaces() );
}
executable.execute();
}
</pre>

== Persisting tainted data ==

* Assume persistent objects have JavaBeans style setter methods as this is most common practice. When these setters are called with tainted parameters consider this object to be tainted.
* We should flag all functions where tainted objects are made persistent. Although most documents will define Session.save() or Session.persist() as making an object persistent, it is actually PENDING until a call to Transaction.commit() is made. Whether or not we want to flag the saves, or the commits is up to scan dev - keep in mind that if we're flagging commit() we must first decide that the code between Transaction.begin() or Session.beginTransaction() and Transaction.commit() contains eevil.
* The only associated cwe I can think of right now is stored xss.

Consider this example:
<pre>
Session session = sessionFactory.getCurrentSession();
String firstname = request.getParameter("firstname");
String lastname = request.getParameter("lastname");

try{
Transaction tx = session.beginTransaction();

Person thePerson = session.load(Person.class, new Long(69));//loading an already persistent object
thePerson.setFirstname(firstname);// then adding tainted data to it
thePerson.setLastname(lastname);
session.save(thePerson); //persisting our changes

session.getTransaction().commit();
} catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
session.close();
</pre>
Most Common Functions:

* Session.save(Object object) - save object to the session, object should not contain tainted data.
* Session.persist(Object object) -
* Session.void replicate(Object object, ReplicationMode?? replicationMode) -
* Session.void saveOrUpdate(Object object) -
* Session.update(Object object)() -
* Session.evict(Object object)() - remove instance from session cache
* Session.clear() - evict all loaded instances
* Session.load(Class theClass, Serializable id) - gets an object from the db for you to manipulate.

[[Category:Hibernate]]
[[Category:OWASP Java Project]]
[[Category:Java]]

Testing Directory traversal/file include (OTG-AUTHZ-001)

2015-04-28T19:05:40Z

Jarrod Stenberg: /* Testing Techniques */

{{Template:OWASP Testing Guide v4}}

== Summary ==
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.

Traditionally, web servers and web applications implement authentication mechanisms to control access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root", which represents a physical directory on the file system. Users have to consider this directory as the base directory into the hierarchical structure of the web application.

The definition of the privileges is made using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to prevent malicious users from accessing sensitive files (for example, the common /etc/passwd file on a UNIX-like platform) or to avoid the execution of system commands.

Many web applications use server-side scripts to include different kinds of files. It is quite common to use this method to manage images, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated.

In web servers and web applications, this kind of problem arises in path traversal/file include attacks. By exploiting this kind of vulnerability, an attacker is able to read directories or files which they normally couldn't read, access data outside the web document root, or include scripts and other kinds of files from external websites.

For the purpose of the OWASP Testing Guide, only the security threats related to web applications will be considered and not threats to web servers (e.g., the infamous "%5c escape code" into Microsoft IIS web server). Further reading suggestions will be provided in the references section for interested readers.

This kind of attack is also known as the dot-dot-slash attack (../), directory traversal, directory climbing, or backtracking.

During an assessment, to discover path traversal and file include flaws, testers need to perform two different stages:
* ('''a''') '''Input Vectors Enumeration''' (a systematic evaluation of each input vector)
* ('''b''') '''Testing Techniques''' (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability)
 

==How to Test==
=== Black Box testing ===
====Input Vectors Enumeration====
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and HTML forms.

Here are some examples of the checks to be performed at this stage:

* Are there request parameters which could be used for file-related operations?
* Are there unusual file extensions?
* Are there interesting variable names?

<pre>
http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
</pre>

* Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates?

<pre>
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
</pre>
 

====Testing Techniques====

The next stage of testing is analyzing the input validation functions present in the web application. Using the previous example, the dynamic page called ''getUserProfile.jsp'' loads static information from a file and shows the content to users. An attacker could insert the malicious string "''../../../../etc/passwd''" to include the password hash file of a Linux/UNIX system. Obviously, this kind of attack is possible only if the validation checkpoint fails; according to the file system privileges, the web application itself must be able to read the file.

To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.

<pre>
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
</pre>

For the cookies example:
<pre>
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
</pre>

It's also possible to include files and scripts located on external website.
<pre>
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
</pre>

If protocols are accepted as arguments, as in the above example, it's also possible to probe the local filesystem this way.
<pre>
http://example.com/index.php?file=file:///etc/passwd
</pre>

If protocols are accepted as arguments, as in the above examples, it's also possible to probe the local services and nearby services.
<pre>
http://example.com/index.php?file=http://localhost:8080 or http://example.com/index.php?file=http://192.168.0.2:9080
</pre>

The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal characters.

<pre>
http://example.com/main.cgi?home=main.cgi
</pre>

The component called "''main.cgi''" is located in the same directory as the normal HTML static files used by the application.
In some cases the tester needs to encode the requests using special characters (like the "'''.'''" dot, "'''%00'''" null, ...) in order to bypass file extension controls or to prevent script execution.

Tip
It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first the test string isn't successful, try another encoding scheme.

Each operating system uses different characters as path separator:

''Unix-like OS'':
<pre>
root directory: "/"
directory separator: "/"
</pre>

''Windows OS' Shell':
<pre>
root directory: "<drive letter>:\"
directory separator: "\" or "/"
</pre>

''Classic Mac OS'':
<pre>
root directory: "<drive letter>:"
directory separator: ":"
</pre>
 

We should take in to account the following character encoding mechanisms:

* URL encoding and double URL encoding

<pre>
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.
</pre>

* Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)

<pre>
..%c0%af represents ../
..%c1%9c represents ..\
</pre>
 

There are other OS and application framework specific considerations as well. For instance, Windows is flexible in its parsing of file paths.

* ''Windows shell'': Appending any of the following to paths used in a shell command results in no difference in function:
** Angle brackets ">" and "<" at the end of the path
** Double quotes (closed properly) at the end of the path
** Extraneous current directory markers such as "./" or ".\"
** Extraneous parent directory markers with arbitrary items that may or may not exist
*: Examples: 

<pre>
– file.txt
– file.txt...
– file.txt<spaces>
– file.txt””””
– file.txt<<<>>><
– ./././file.txt
– nonexistant/../file.txt
</pre>

* ''Windows API'': The following items are discarded when used in any shell command or API call where a string is taken as a filename: 
<pre>
periods
spaces
</pre>

* ''Windows UNC Filepaths'': Used to reference files on SMB shares. Sometimes, an application can be made to refer to files on a remote UNC filepath. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked. These may also be used with a self-referential IP address or domain name to evade filters, or used to access files on SMB shares inaccessible to the attacker, but accessible from the web server. 
<pre>
\\server_or_ip\path\to\file.abc
\\?\server_or_ip\path\to\file.abc
</pre>

* ''Windows NT Device Namespace'': Used to refer to the Windows device namespace. Certain references will allow access to file systems using a different path.
** May be equivalent to a drive letter such as c:\, or even a drive volume without an assigned letter. <pre>\\.\GLOBALROOT\Device\HarddiskVolume1\</pre>
** Refers to the first disc drive on the machine. <pre>\\.\CdRom0\</pre>

=== Gray Box testing ===
When the analysis is performed with a Gray Box approach, testers have to follow the same methodology as in Black Box Testing. However, since they can review the source code, it is possible to search the input vectors (''stage ('''a''') of the testing'') more easily and accurately. During a source code review, they can use simple tools (such as the ''grep'' command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.

<pre>
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...
</pre>

Using online code search engines (e.g., Ohloh Code[http://code.ohloh.net/]), it may also be possible to find path traversal flaws in Open Source software published on the Internet.

For PHP, testers can use:
<pre>
lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)
</pre>
 

Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible to find during a standard Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted path traversal strings when the application adds data to the database. This kind of security problem is difficult to discover due to the fact the parameters inside the inclusion functions seem internal and "safe" but are not in reality.

Additionally, by reviewing the source code it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.

Consider a web application with these instructions:
<pre>
filename = Request.QueryString(“file”);
Replace(filename, “/”,”\”);
Replace(filename, “..\”,””);
</pre>

Testing for the flaw is achieved by:
<pre>
file=....//....//boot.ini
file=....\\....\\boot.ini
file= ..\..\boot.ini
</pre>
 

==Tools==
* DotDotPwn - The Directory Traversal Fuzzer - http://dotdotpwn.sectester.net
* Path Traversal Fuzz Strings (from WFuzz Tool) - http://code.google.com/p/wfuzz/source/browse/trunk/wordlist/Injections/Traversal.txt
* Web Proxy (''Burp Suite''[http://portswigger.net], ''Paros''[http://www.parosproxy.org/index.shtml], ''WebScarab''[http://www.owasp.org/index.php/OWASP_WebScarab_Project],''OWASP: Zed Attack Proxy (ZAP)''[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project])
* Enconding/Decoding tools
* String searcher "grep" - http://www.gnu.org/software/grep/

== References ==
'''Whitepapers'''
* phpBB Attachment Mod Directory Traversal HTTP POST Injection - http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html[http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html]
* Windows File Pseudonyms: Pwnage and Poetry - http://www.slideshare.net/BaronZor/windows-file-pseudonyms[http://www.slideshare.net/BaronZor/windows-file-pseudonyms]

Testing Directory traversal/file include (OTG-AUTHZ-001)

2015-04-28T19:05:07Z

Jarrod Stenberg: /* Testing Techniques */ Added additional fun to be had with URL as malicious input.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.

Traditionally, web servers and web applications implement authentication mechanisms to control access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root", which represents a physical directory on the file system. Users have to consider this directory as the base directory into the hierarchical structure of the web application.

The definition of the privileges is made using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to prevent malicious users from accessing sensitive files (for example, the common /etc/passwd file on a UNIX-like platform) or to avoid the execution of system commands.

Many web applications use server-side scripts to include different kinds of files. It is quite common to use this method to manage images, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated.

In web servers and web applications, this kind of problem arises in path traversal/file include attacks. By exploiting this kind of vulnerability, an attacker is able to read directories or files which they normally couldn't read, access data outside the web document root, or include scripts and other kinds of files from external websites.

For the purpose of the OWASP Testing Guide, only the security threats related to web applications will be considered and not threats to web servers (e.g., the infamous "%5c escape code" into Microsoft IIS web server). Further reading suggestions will be provided in the references section for interested readers.

This kind of attack is also known as the dot-dot-slash attack (../), directory traversal, directory climbing, or backtracking.

During an assessment, to discover path traversal and file include flaws, testers need to perform two different stages:
* ('''a''') '''Input Vectors Enumeration''' (a systematic evaluation of each input vector)
* ('''b''') '''Testing Techniques''' (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability)
 

==How to Test==
=== Black Box testing ===
====Input Vectors Enumeration====
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and HTML forms.

Here are some examples of the checks to be performed at this stage:

* Are there request parameters which could be used for file-related operations?
* Are there unusual file extensions?
* Are there interesting variable names?

<pre>
http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
</pre>

* Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates?

<pre>
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
</pre>
 

====Testing Techniques====

The next stage of testing is analyzing the input validation functions present in the web application. Using the previous example, the dynamic page called ''getUserProfile.jsp'' loads static information from a file and shows the content to users. An attacker could insert the malicious string "''../../../../etc/passwd''" to include the password hash file of a Linux/UNIX system. Obviously, this kind of attack is possible only if the validation checkpoint fails; according to the file system privileges, the web application itself must be able to read the file.

To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.

<pre>
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
</pre>

For the cookies example:
<pre>
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
</pre>

It's also possible to include files and scripts located on external website.
<pre>
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
</pre>

If protocols are accepted as arguments, as in the above example, it's also possible to probe the local filesystem this way.
<pre>
http://example.com/index.php?file=file:///etc/passwd
</pre>

If protocols are accepted as arguments, as in the above examples, it's also possible to probe the local services (e.g., http://localhost...) and nearby services.
<pre>
http://example.com/index.php?file=http://localhost:8080 or http://example.com/index.php?file=http://192.168.0.2:9080
</pre>

The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal characters.

<pre>
http://example.com/main.cgi?home=main.cgi
</pre>

The component called "''main.cgi''" is located in the same directory as the normal HTML static files used by the application.
In some cases the tester needs to encode the requests using special characters (like the "'''.'''" dot, "'''%00'''" null, ...) in order to bypass file extension controls or to prevent script execution.

Tip
It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first the test string isn't successful, try another encoding scheme.

Each operating system uses different characters as path separator:

''Unix-like OS'':
<pre>
root directory: "/"
directory separator: "/"
</pre>

''Windows OS' Shell':
<pre>
root directory: "<drive letter>:\"
directory separator: "\" or "/"
</pre>

''Classic Mac OS'':
<pre>
root directory: "<drive letter>:"
directory separator: ":"
</pre>
 

We should take in to account the following character encoding mechanisms:

* URL encoding and double URL encoding

<pre>
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.
</pre>

* Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)

<pre>
..%c0%af represents ../
..%c1%9c represents ..\
</pre>
 

There are other OS and application framework specific considerations as well. For instance, Windows is flexible in its parsing of file paths.

* ''Windows shell'': Appending any of the following to paths used in a shell command results in no difference in function:
** Angle brackets ">" and "<" at the end of the path
** Double quotes (closed properly) at the end of the path
** Extraneous current directory markers such as "./" or ".\"
** Extraneous parent directory markers with arbitrary items that may or may not exist
*: Examples: 

<pre>
– file.txt
– file.txt...
– file.txt<spaces>
– file.txt””””
– file.txt<<<>>><
– ./././file.txt
– nonexistant/../file.txt
</pre>

* ''Windows API'': The following items are discarded when used in any shell command or API call where a string is taken as a filename: 
<pre>
periods
spaces
</pre>

* ''Windows UNC Filepaths'': Used to reference files on SMB shares. Sometimes, an application can be made to refer to files on a remote UNC filepath. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked. These may also be used with a self-referential IP address or domain name to evade filters, or used to access files on SMB shares inaccessible to the attacker, but accessible from the web server. 
<pre>
\\server_or_ip\path\to\file.abc
\\?\server_or_ip\path\to\file.abc
</pre>

* ''Windows NT Device Namespace'': Used to refer to the Windows device namespace. Certain references will allow access to file systems using a different path.
** May be equivalent to a drive letter such as c:\, or even a drive volume without an assigned letter. <pre>\\.\GLOBALROOT\Device\HarddiskVolume1\</pre>
** Refers to the first disc drive on the machine. <pre>\\.\CdRom0\</pre>

=== Gray Box testing ===
When the analysis is performed with a Gray Box approach, testers have to follow the same methodology as in Black Box Testing. However, since they can review the source code, it is possible to search the input vectors (''stage ('''a''') of the testing'') more easily and accurately. During a source code review, they can use simple tools (such as the ''grep'' command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.

<pre>
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...
</pre>

Using online code search engines (e.g., Ohloh Code[http://code.ohloh.net/]), it may also be possible to find path traversal flaws in Open Source software published on the Internet.

For PHP, testers can use:
<pre>
lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)
</pre>
 

Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible to find during a standard Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted path traversal strings when the application adds data to the database. This kind of security problem is difficult to discover due to the fact the parameters inside the inclusion functions seem internal and "safe" but are not in reality.

Additionally, by reviewing the source code it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.

Consider a web application with these instructions:
<pre>
filename = Request.QueryString(“file”);
Replace(filename, “/”,”\”);
Replace(filename, “..\”,””);
</pre>

Testing for the flaw is achieved by:
<pre>
file=....//....//boot.ini
file=....\\....\\boot.ini
file= ..\..\boot.ini
</pre>
 

==Tools==
* DotDotPwn - The Directory Traversal Fuzzer - http://dotdotpwn.sectester.net
* Path Traversal Fuzz Strings (from WFuzz Tool) - http://code.google.com/p/wfuzz/source/browse/trunk/wordlist/Injections/Traversal.txt
* Web Proxy (''Burp Suite''[http://portswigger.net], ''Paros''[http://www.parosproxy.org/index.shtml], ''WebScarab''[http://www.owasp.org/index.php/OWASP_WebScarab_Project],''OWASP: Zed Attack Proxy (ZAP)''[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project])
* Enconding/Decoding tools
* String searcher "grep" - http://www.gnu.org/software/grep/

== References ==
'''Whitepapers'''
* phpBB Attachment Mod Directory Traversal HTTP POST Injection - http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html[http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html]
* Windows File Pseudonyms: Pwnage and Poetry - http://www.slideshare.net/BaronZor/windows-file-pseudonyms[http://www.slideshare.net/BaronZor/windows-file-pseudonyms]

Testing for Weak lock out mechanism (OTG-AUTHN-003)

2015-04-28T18:39:39Z

Jarrod Stenberg: /* How to Test */ Added note about weak client-side implementations. These are common amongst untrained developers.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Account lockout mechanisms are used to mitigate brute force password guessing attacks. Accounts are typically locked after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. 

Note that this test should cover all aspects of authentication where lockout mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see [[Testing for Weak security question/answer (OTG-AUTHN-008)]]).

Without a strong lockout mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:

* Confidential information or data: Private sections of a web application could disclose confidential documents, users' profile data, financial information, bank details, users' relationships, etc.

* Administration panels: These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc.

* Opportunities for further attacks: authenticated sections of a web application could contain vulnerabilities that are not present in the public section of the web application and could contain advanced functionality that is not available to public users.

== Test objectives ==

# Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.
# Evaluate the unlock mechanism's resistance to unauthorized account unlocking.

== How to Test==

Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing or can afford to lock. If you have only one account with which you can log on to the web application, perform this test at the end of you test plan to avoid that you cannot continue your testing due to a locked account. 
 

To evaluate the account lockout mechanism's ability to mitigate brute force password guessing, attempt an invalid log in by using the incorrect password a number of times, before using the correct password to verify that the account was locked out. An example test may be as follows:
# Attempt to log in with an incorrect password 3 times.
# Successfully log in with the correct password, thereby showing that the lockout mechanism doesn't trigger after 3 incorrect authentication attempts.
# Attempt to log in with an incorrect password 4 times.
# Successfully log in with the correct password, thereby showing that the lockout mechanism doesn't trigger after 4 incorrect authentication attempts.
# Attempt to log in with an incorrect password 5 times.
# Attempt to log in with the correct password. The application returns "Your account is locked out.", thereby confirming that the account is locked out after 5 incorrect authentication attempts.
# Attempt to log in with the correct password 5 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
# Attempt to log in with the correct password 10 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
# Successfully log in with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
 

A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see [[Testing_for_Captcha_(OWASP-AT-012)|Testing for CAPTCHA]]), and should not replace a lockout mechanism.

 
To evaluate the unlock mechanism's resistance to unauthorized account unlocking, initiate the unlock mechanism and look for weaknesses. Typical unlock mechanisms may involve secret questions or an emailed unlock link. The unlock link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches. Secret questions and answers should be strong (see [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak Security Question/Answer]]). 

Note that an unlock mechanism should only be used for unlocking accounts. It is not the same as a password recovery mechanism. 
 
Factors to consider when implementing an account lockout mechanism:

# What is the risk of brute force password guessing against the application?
# Is a CAPTCHA sufficient to mitigate this risk?
# Is a client-side lockout mechanism being used (e.g., Javascript)? (If so, disable the client-side code to test.)
# Number of unsuccessful log in attempts before lockout. If the lockout threshold is to low then valid users may be locked out too often. If the lockout threshold is to high then the more attempts an attacker can make to brute force the account before it will be locked. Depending on the application's purpose, a range of 5 to 10 unsuccessful attempts is typical lockout threshold.
# How will accounts be unlocked?
## Manually by an administrator: this is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.
### Note that the administrator should also have a recovery method in case his account gets locked.
### This unlock mechanism may lead to a denial-of-service attack if an attacker's goal is to lock the accounts of all users of the web application.
## After a period of time: What is the lockout duration? Is this sufficient for the application being protected? E.g. a 5 to 30 minute lockout duration may be a good compromise between mitigating brute force attacks and inconveniencing valid users.
## Via a self-service mechanism: As stated before, this self-service mechanism must be secure enough to avoid that the attacker can unlock accounts himself.

== References ==

See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.

== Remediation ==

Apply account unlock mechanisms depending on the risk level. In order from lowest to highest assurance:

# Time-based lockout and unlock.
# Self-service unlock (sends unlock email to registered email address).
# Manual administrator unlock.
# Manual administrator unlock with positive user identification.

Test Network/Infrastructure Configuration (OTG-CONFIG-001)

2015-04-28T17:46:24Z

Jarrod Stenberg: Added objectives section.

{{Template:OWASP Testing Guide v4}}

== Summary ==
The intrinsic complexity of interconnected and heterogeneous web server infrastructure, which can include hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application.
It takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and seemingly unimportant problems may evolve into severe risks for another application on the same server. In order to address these problems, it is of utmost importance to perform an in-depth review of configuration and known security issues, after having mapped the entire architecture.

Proper configuration management of the web server infrastructure is very important in order to preserve the security of the application itself. If elements such as the web server software, the back-end database servers, or the authentication servers are not properly reviewed and secured, they might introduce undesired risks or introduce new vulnerabilities that might compromise the application itself.

For example, a web server vulnerability that would allow a remote attacker to disclose the source code of the application itself (a vulnerability that has arisen a number of times in both web servers or application servers) could compromise the application, as anonymous users could use the information disclosed in the source code to leverage attacks against the application or its users.

The following steps need to be taken to test the configuration management infrastructure:

* The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.
* All the elements of the infrastructure need to be reviewed in order to make sure that they don’t contain any known vulnerabilities.
* A review needs to be made of the administrative tools used to maintain all the different elements.
* The authentication systems, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.
* A list of defined ports which are required for the application should be maintained and kept under change control.

After having mapped the different elements that make up the infrastructure (see [[Map_Network_and_Application_Architecture_(OTG-INFO-012)|Map Network and Application Architecture]]) it is possible to review the configuration of each element founded and test for any known vulnerabilities.

== Test Objectives ==
Map the infrastructure supporting the application and understand how it affects the security of the application.

== How to Test==

===Known Server Vulnerabilities===
Vulnerabilities found in the different areas of the application architecture, be it in the web server or in the back end database, can severely compromise the application itself. For example, consider a server vulnerability that allows a remote, unauthenticated user to upload files to the web server or even to replace files. This vulnerability could compromise the application, since a rogue user may be able to replace the application itself or introduce code that would affect the back end servers, as its application code would be run just like any other application.

Reviewing server vulnerabilities can be hard to do if the test needs to be done through a blind penetration test. In these cases, vulnerabilities need to be tested from a remote site, typically using an automated tool. However, testing for some vulnerabilities can have unpredictable results on the web server, and testing for others (like those directly involved in denial of service attacks) might not be possible due to the service downtime involved if the test was successful.

Some automated tools will flag vulnerabilities based on the web server version retrieved. This leads to both false positives and false negatives. On one hand, if the web server version has been removed or obscured by the local site administrator the scan tool will not flag the server as vulnerable even if it is. On the other hand, if the vendor providing the software does not update the web server version when vulnerabilities are fixed, the scan tool will flag vulnerabilities that do not exist. The latter case is actually very common as some operating system vendors back port patches of security vulnerabilities to the software they provide in the operating system, but do not do a full upload to the latest software version. This happens in most GNU/Linux distributions such as Debian, Red Hat or SuSE. In most cases, vulnerability scanning of an application architecture will only find vulnerabilities associated with the “exposed” elements of the architecture (such as the web server) and will usually be unable to find vulnerabilities associated to elements which are not directly exposed, such as the authentication back ends, the back end database, or reverse proxies in use.

Finally, not all software vendors disclose vulnerabilities in a public way, and therefore these weaknesses do not become registered within publicly known vulnerability databases[2]. This information is only disclosed to customers or published through fixes that do not have accompanying advisories. This reduces the usefulness of vulnerability scanning tools. Typically, vulnerability coverage of these tools will be very good for common products (such as the Apache web server, Microsoft’s Internet Information Server, or IBM’s Lotus Domino) but will be lacking for lesser known products.

This is why reviewing vulnerabilities is best done when the tester is provided with internal information of the software used, including versions and releases used and patches applied to the software. With this information, the tester can retrieve the information from the vendor itself and analyze what vulnerabilities might be present in the architecture and how they can affect the application itself. When possible, these vulnerabilities can be tested to determine their real effects and to detect if there might be any external elements (such as intrusion detection or prevention systems) that might reduce or negate the possibility of successful exploitation. Testers might even determine, through a configuration review, that the vulnerability is not even present, since it affects a software component that is not in use.

It is also worthwhile to note that vendors will sometimes silently fix vulnerabilities and make the fixes available with new software releases. Different vendors will have different release cycles that determine the support they might provide for older releases. A tester with detailed information of the software versions used by the architecture can analyse the risk associated to the use of old software releases that might be unsupported in the short term or are already unsupported. This is critical, since if a vulnerability were to surface in an old software version that is no longer supported, the systems personnel might not be directly aware of it. No patches will be ever made available for it and advisories might not list that version as vulnerable as it is no longer supported. Even in the event that they are aware that the vulnerability is present and the system is vulnerable, they will need to do a full upgrade to a new software release, which might introduce significant downtime in the application architecture or might force the application to be re-coded due to incompatibilities with the latest software version.

===Administrative tools===

Any web server infrastructure requires the existence of administrative tools to maintain and update the information used by the application. This information includes static content (web pages, graphic files), application source code, user authentication databases, etc. Administrative tools will differ depending on the site, technology, or software used. For example, some web servers will be managed using administrative interfaces which are, themselves, web servers (such as the iPlanet web server) or will be administrated by plain text configuration files (in the Apache case[3]) or use operating-system GUI tools (when using Microsoft’s IIS server or ASP.Net). I

n most cases the server configuration will be handled using different file maintenance tools used by the web server, which are managed through FTP servers, WebDAV, network file systems (NFS, CIFS) or other mechanisms. Obviously, the operating system of the elements that make up the application architecture will also be managed using other tools. Applications may also have administrative interfaces embedded in them that are used to manage the application data itself (users, content, etc.).

After having mapped the administrative interfaces used to manage the different parts of the architecture it is important to review them since if an attacker gains access to any of them he can then compromise or damage the application architecture. To do this it is important to:

* Determine the mechanisms that control access to these interfaces and their associated susceptibilities. This information may be available online.
* Change the default username and password.

Some companies choose not to manage all aspects of their web server applications, but may have other parties managing the content delivered by the web application. This external company might either provide only parts of the content (news updates or promotions) or might manage the web server completely (including content and code). It is common to find administrative interfaces available from the Internet in these situations, since using the Internet is cheaper than providing a dedicated line that will connect the external company to the application infrastructure through a management-only interface. In this situation, it is very important to test if the administrative interfaces can be vulnerable to attacks.

==References==
* [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework.
* [2] Such as Symantec’s Bugtraq, ISS’ X-Force, or NIST’s National Vulnerability Database (NVD).
* [3] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet.

User:Jarrod Stenberg

2014-05-28T20:15:47Z

Jarrod Stenberg:

I started out on an 800XL in '83 and have been a computer geek ever since. I've worked in security for about 10 years and 20 years in development, system administration, and just about anything IT related.

I have worked for over 9 years in a Fortune 20 company, 7 within Information Risk Management Security Architecture.

User:Jarrod Stenberg

2014-05-28T20:14:47Z

Jarrod Stenberg:

How to write insecure code

2010-02-10T15:39:10Z

Jarrod Stenberg: /* Magical thinking */ Added VPN.

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

==Jedi Mind Tricks==
; '''Defensive Insecurity: Always be ready with a good offense.'''
===Your project is too important===
* This project is too important to consider these negative security findings.

===You're too important===
* Don't you know who I am?
===They are not important===
* Who are you to question this?
===You know important people===
* I was having a beer with Joe Topexec yesterday, and he really wants to see this project online.
===Too late===
* This has to be released tomorrow night at 10 PM. We have SLAs to satisfy.
===Vague references===
* We got approval from the security team over a year ago on this.
===Precedence===
* This has been done this way for 5 years so why does it matter now?
* Everyone else does it this way, why are you making me deal with it?
===Magical thinking===
* It's internal network only, so security doesn't matter.
* It's secure because it's over VPN.
* I thought the firewalls were supposed to do that.
* My application is different.

[[Category:How To]]

How to write insecure code

2010-02-09T19:59:35Z

Jarrod Stenberg: /* Defensive Insecurity */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

==Jedi Mind Tricks==
; '''Defensive Insecurity: Always be ready with a good offense.'''
===Your project is too important===
* This project is too important to consider these negative security findings.

===You're too important===
* Don't you know who I am?
===They are not important===
* Who are you to question this?
===You know important people===
* I was having a beer with Joe Topexec yesterday, and he really wants to see this project online.
===Too late===
* This has to be released tomorrow night at 10 PM. We have SLAs to satisfy.
===Vague references===
* We got approval from the security team over a year ago on this.
===Precedence===
* This has been done this way for 5 years so why does it matter now?
* Everyone else does it this way, why are you making me deal with it?
===Magical thinking===
* It's internal network only, so security doesn't matter.
* I thought the firewalls were supposed to do that.
* My application is different.

[[Category:How To]]

How to write insecure code

2010-02-05T21:43:39Z

Jarrod Stenberg: /* Your project too important */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

==Defensive Insecurity==
; '''Always be ready with a good offense.'''
===Your project is too important===
* This project is too important to consider these negative security findings.

===You're too important===
* Don't you know who I am?
===They are not important===
* Who are you to question this?
===You know important people===
* I was having a beer with Joe Topexec yesterday, and he really wants to see this project online.
===Too late===
* This has to be released tomorrow night at 10 PM. We have SLAs to satisfy.
===Vague references===
* We got approval from the security team over a year ago on this.
===Precedence===
* This has been done this way for 5 years so why does it matter now?
* Everyone else does it this way, why are you making me deal with it?
===Magical thinking===
* It's internal network only, so security doesn't matter.
* I thought the firewalls were supposed to do that.
* My application is different.

[[Category:How To]]

How to write insecure code

2010-02-05T21:43:18Z

Jarrod Stenberg: /* Libraries */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

==Defensive Insecurity==
; '''Always be ready with a good offense.'''
===Your project too important===
* This project is too important to consider these negative security findings.
===You're too important===
* Don't you know who I am?
===They are not important===
* Who are you to question this?
===You know important people===
* I was having a beer with Joe Topexec yesterday, and he really wants to see this project online.
===Too late===
* This has to be released tomorrow night at 10 PM. We have SLAs to satisfy.
===Vague references===
* We got approval from the security team over a year ago on this.
===Precedence===
* This has been done this way for 5 years so why does it matter now?
* Everyone else does it this way, why are you making me deal with it?
===Magical thinking===
* It's internal network only, so security doesn't matter.
* I thought the firewalls were supposed to do that.
* My application is different.

[[Category:How To]]

How to write insecure code

2010-02-05T20:59:21Z

Jarrod Stenberg: /* General Principles */

How to write insecure code

2010-02-05T20:53:32Z

Jarrod Stenberg: /* Trust Relationships */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T20:51:13Z

Jarrod Stenberg: /* Trust Relationships */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T20:48:58Z

Jarrod Stenberg: /* Authorization */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T20:41:30Z

Jarrod Stenberg: /* Documentation */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T20:31:08Z

Jarrod Stenberg: /* Authorization */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T20:30:37Z

Jarrod Stenberg: /* Input Validation */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T20:29:57Z

Jarrod Stenberg: /* Input Validation */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:33:37Z

Jarrod Stenberg: /* Policy */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:32:09Z

Jarrod Stenberg: /* Policy */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime readable format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:30:13Z

Jarrod Stenberg: /* Authorization */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both. Let your authentication technology dictate your authorization requirements.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime readable format.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:22:35Z

Jarrod Stenberg: /* Authentication */ Added Access Control section

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:21:24Z

Jarrod Stenberg: /* Authorization */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:19:49Z

Jarrod Stenberg: /* Access Control */ Moved to Authorization

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

See Authentication. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:17:45Z

Jarrod Stenberg: /* Authorization */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

See Authentication. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:11:31Z

Jarrod Stenberg: /* Authentication */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

See [Authentication].

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T19:10:21Z

Jarrod Stenberg: /* Encryption */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T18:58:03Z

Jarrod Stenberg: /* Authentication */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T18:57:44Z

Jarrod Stenberg: /* Encryption */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T18:52:36Z

Jarrod Stenberg: /* Encryption */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T18:01:44Z

Jarrod Stenberg: /* Encryption */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to know how to encrypt it again and create the blob themselves.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T18:00:22Z

Jarrod Stenberg: /* Encryption */

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to know how to encrypt it again and create the blob themselves.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

==Access Control==

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

==Documentation==

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

[[Category:How To]]

How to write insecure code

2010-02-05T17:41:55Z

Jarrod Stenberg: /* Trust Relationships */

How to write insecure code

2010-02-05T17:38:47Z

Jarrod Stenberg: /* General Principles */ Fixed typo.