Natural Order Development

Interesting challenge:

What is wrong with these cookies?

Set-Cookie: LSID=FDDGAAK…Eaem_vYg; Domain=repo.nodsw.com;
Path=/; Expires=Mon, 11-Jul-2016 10:30:11 GMT; 

Set-Cookie: SSID=Xv4P...DFGaq; Domain=.nodsw.com;
Path=/; Expires=Wed, 11-Jul-2016 10:30:11 GMT;

I'll post the explanations from a security bulletin later.

I was reading one of my weekly computer news letters and was surprised to learn that over four million computers world wide with roughly 500,000 in the US are still infected with an old DNS hack/virus called DNSChanger which USE to take you off to very interesting snake salesmen sites. It is not difficult to fix, the US Government took down the people doing it (which is a shocker but a nice one), took over their internet servers (which is another shocker), and made it so infected systems actually work correctly (which is really the surprising bit).

I prefer simple things over complex. So naturally I like easy to read URLs and I strive to keep URLs on sites I work on from getting out of control. So I appreciate the idea and the results of compact URL services like is.gd and TinyURL. I also understand the need to more accurately track incoming hits for marketing and usage statistics. But these self same services are also used by less noble people who create malicious sites for illicit fun or profit.

Everyone who has an email box and a friend or two gets semi regular stuff in the form of shared jokes. Sometimes stuff comes around multiple times. What is really interesting is how something that has already been around once not too long ago generates entirely different responses on the second pass.

This is from a place I worked at. It is a really great idea so I have summarized it here in case some other place wishes to implement a similar procedure. The original work was done by a really great guy named Marc Wensauer (http://www.linkedin.com/in/marcwensauer).

Purpose

A mechanism to provide an indication to a user that he or she has left a system unattended with an unprotected, active user interface.

The question is always what can be considered safe when dealing with user input. (In truth very little.) However, setting that truism aside, sites can use HTML correction modules to correct input, and then escaping any oddness. After initial scrubbing the question is what should be allowed through to assist in displaying the content as the author wishes. That list is kind of hard to find. Here is my basic list.

Block-level tags

ADDRESS

Information about the author (such as contact info)

BLOCKQUOTE

Extended quotation

As things ramp up for NOD Software a lot of time is being spent on the learning curve. One of the largest concerns is of course security. NOD Software supports a number of organizations and projects. Most of what is done for the primary site eventually is used to enhance our supported sites. At this stage it is all about pulling together a minimal configuration that provides a solid set of features.

Running around the Internet produces a lot of crumbs to follow. I thought perhaps I should share these as anyone else might be interested in all the circles we are running in.

Sometimes a little curiosity is scary. For example I was Googling on term "anonymous surfing" and found some articles:

• http://en.wikipedia.org/wiki/Anonymous_web_browsing
• http://www.tech-faq.com/anonymous-surfing.shtml
• http://www.auditmypc.com/anonymous-surfing.asp -- This one is interesting because it will tell you how much information it gathered on you

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:

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

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;
  

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:

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

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

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'