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).
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.
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:
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:
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:
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:
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:
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'