best practices

warning: Creating default object from empty value in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/modules/taxonomy/taxonomy.pages.inc on line 33.
Leeland's picture

It's Done When?

Been dealing a lot of SCRUM items and it seems to me that a lot of teams keep missing the mark because of not clear "done criteria". For the record I think a minimum done criteria is:
  • Code is checked-in into a central version control system
  • A detailed code review (including comparison to any company and/or team coding standards) has been complete, any suggested changes implemented and final code has been checked-in
  • Unit tests with demonstratable cover coverage of more 80% for non-integration / "out of container"
Leeland's picture

Defensive Java Programming Notes (11 of 11) Top 13 Best Practices

Best Practice #1 Do Input Validation

Input validation verifies or cleans up inputs to the application. Essentially trust no data from any source until it has been proven to be safe based on some established format verification process. Input validation is a critical part of a web service's reliability and security (or any software application for that matter). By failing to validate input data an application may do very unexpected things given a garbled (accidentally or intentionally) input leading to a security violation or a vulnerable state.

Input Validation:

Leeland's picture

Defensive Java Programming Notes (10 of 11) Web Container Security Features

Warning this is amazingly boring.



Web containers are things like Apache Tomcat, WebSphere, Java Systems Webserver, JBOSS, Weblogic, and lots more.



There are some common things:

  • Web applications created by developers

  • Security needs for a given web application are usually deployment-specific

  • Deployers should be able to specify security settings without changing application code


Leeland's picture

Defensive Java Programming Notes (09 of 11) Poorly Implemented Cryptography

Cryptography is effective only if it is used properly. It is way too easy to use very strong cryptography libraries very wrong. The most common problems with cryptography implementations are:

  • Use of home grown algorithms (lets face it unless you have a PhD in mathematics and another in cryptography you should not write a cryptographic algorithm for a production system.);

  • Cryptography depends on REALLY random seed data and the standard rand() calls are NOT random enough for strong enough cryptographic functions let alone strong cryptographic solutions;

Leeland's picture

Defensive Java Programming Notes (08 of 11) Information Disclosure

There is never any reason to dump detailed data out to the users. Log it, maybe tack on an error ID to it and then send a message to the user that there was an error.



Web applications should never dump data like stack traces, ODBC error messages, authentication error messages, or anything else that exposes a detail about the implementation of the site.



Sometimes error message or unexpected outputs give an attacker a significant advantage in attacking a system. Examples of useful information that will aid an attacker are:

Leeland's picture

Defensive Java Programming Notes (07 of 11) HTTP Response Splitting

This is where an attacker is able to convince the browser that there where actually two HTTP responses and the browser thinks the second response is the body, which would be completely controlled by the attacker.

Example:

http://paradox.org/~attacker/redirect.php?page=http://www.evilSite.org

Would direct the user's browser to http://www.evilSite.org

Typically this is used to do other kinds of attacks like:

  • Cross-Site Scripting
Leeland's picture

Defensive Java Programming Notes (06 of 11) Cross-Site Request Forgery (CSRF or XSRF)

Tricks the victim's browser into performing (undesirable) actions on behalf of the victim. There is no EASY way for the site to tell if a request submitted is valid or a XSRF attack because this attack causes the browser to do exactly what it is supposed to do using those behaviors against the victim. Examples are:

  • Transfer Funds
  • Changing Passwords
  • Purchasing an Item
Leeland's picture

Defensive Java Programming Notes (05 of 11) SQL Injection

Problem: Embedding user input into SQL queries is BAD!

String SQL = "SELECT Username, Password " +
  "FROM users " +
  "WHERE Username='" + Username + "' " +
  "AND Password ='" + Password + "'";
s.execute(SQL)

So what if in the password field you put in: X' OR 1=1; --

That will turn the SQL statment into:

SELECT Username, Password FROM users WHERE Username='InputName'
Leeland's picture

Defensive Java Programming Notes (04 of 11) Napkin

Napkin - Encoding and Decoding Tool Napkin is an encoding and decoding tool designed for quick manipulation of information when working on web applications. It's not overly robust for large amounts of information, but it comes in handy every so often.
  • Supports multiple common encoding formats
  • Hex representation of all data
  • Can display numerical conversions
  • Can encode and decode HTML and base 64 data
Homepage at: http://www.0x90.org/releases/napkin/index.php
Leeland's picture

Defensive Java Programming Notes (03 of 11) Think Evil

As a developer you need to wear an evil hat when you think about testing your applications.

There are a proliferation of security failures, the rate of breaches and the cost of breaches are going up alarmingly.

2005 - $138 million cost of breaches
2006 - $182 million cost of breaches
2007 - $197 million cost of breaches

Proliferation:

- TJX Corporation: 95 million credit card numbers stolen
- Amertrade: 6.3 million customer records compromised
- Hannaford Bros: 4.2 million credit card numbers stolen
- Monster.com: 1.6 million customer records compromised

Leeland's picture

Defensive Java Programming Notes (02 of 11) Cross Site Scripting

Cross Site Scripting vulnerability started with Sammy on MySpace. Before that XSS vulnerability was known but not really considered a big deal.

Using XSS an attacker can:

  • Hijack your account
  • Spread web worms
  • Access your browser history and clipboard contents
  • Remotely control your browser
  • Scan and exploit you intranet appliances and applications
  • Alter your router's DNS settings and control every webpage you visit thereafter
Leeland's picture

Defensive Java Programming Notes (01 of 11) Introduction

Taking a course on Defensive Java Web Programming presented by Kevin Poniatowski from Security Innovation http://www.securityinnovation.com and there are a lot of cool things to think about and remember. So starting this thread so I can write notes essentially to myself, but hey why not share.

"Threat trend data shows that applications are more commonly attacked than the perimeter"
Depository Trust and Clearance Corporation

Leeland's picture

How to Write 3v1L, Untestable Code

I always love a good laugh and this one is great. The developers and testers at Google have put up a great "How to Write 3v1L, Untestable Code" article with tongue in cheek and enough sarcasm to really tickle your thought processes. In reality is a list of things not to do as a developer. I love the reverse style delivery. You can find the complete post here: Google Testing Blog (http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-c...).

Leeland's picture

Minimizing the Attack Surface

Chris Eng has written two excellent articles on development considerations:

Thread Slivers eBook at Amazon

Syndicate content