Tag Archives: web application security

Why the security war will never be won

At security trade shows like RSA, we are purposefully given the impression that if we just employ some new defensive technique or purchase some new defensive tool, we will be able to keep intruders out of our systems for good.

How many times have we heard this? And how is this different from remedies that promise to solve other problems like our finances or our physical appearance?

The information security war will never be won.

Never.

As long as people, or groups of people, have accumulated wealth of any kind. Other people try to steal it. We can keep ahead of the thieves for a time, as our defenses sometimes prove better than their offensive capabilities. But the wealth is still there, proving to be such a tempting challenge to some that they will use all of their imaginative powers to find a way in.

In our homes, we have better locks, stronger doors, better windows, better alarm systems – for what?  It doesn’t seem like the problems of residential burglaries is getting any better, despite these improvements. Thieves simply improve their techniques and find a way around our defenses.

In our information systems, we have better firewalls, application firewalls, intrusion prevention systems, anti-malware, and a host of other defensive (and even some offensive) security controls. But intruders still find a way in.

There are times when it proves very challenging to break directly in to information systems.  That is when intruders switch tactics: they target personnel who are employed in the organization that owns the systems, using a variety of techniques to trick users into performing seemingly harmless tasks that give intruders the beachhead they need.

Why do intruders persist?  Because of the wealth that lies in the target systems. Whether this is direct monetary wealth, or information that can be traded for monetary wealth, as long as the information is there, and no matter what measures are used to protect the information, intruders will find a way to retrieve it. This is true, even if you have all of the latest defenses, tools, training, and so on.  Your defenses will only slow down a determined intruder, and maybe only be a small margin.

  • We must protect all systems. An intruder will attack the system of his choosing.
  • We must protect from all types of attacks. An intruder will use an attack method of his choosing.
  • We must protect our systems at all times. An intruder will attack at a time of his choosing.
  • We must teach all personnel to be aware of threats. An intruder will attack the person of his choosing.
  • We must obey all laws when defending our systems. An intruder may break any law of his choosing.
  • The intruder will always choose the path of least resistance, the weakest link, at our most vulnerable time.
  • Intruders are patient and resourceful, and often well-funded, and often more motivated by the prospect of success than we are by the prospect of intrusion.

Taking a Wider View of Application Security

Bookmark This (opens in new window)

As a software developer, you have a lot to worry about when writing and testing your code. But if you faithfully use secure coding guidelines from the Open Web Application Security Project (OWASP), test your code with security tools, and conduct peer code reviews, then your application will be secure, giving you worry-free sleep at night.

Wrong.

OK, sorry about that. I put that trap there for you, but I didn’t really expect you to step into it. I want to help you expand your thinking about application security.

Read rest of article here (redirects to softwaremag.com)

Countermeasures for web application parameter tampering attacks

Bookmark This (opens in new window)

A parameter tampering attack is a malicious attack on an application where the attacker is manipulating hidden form variables in an attempt to disrupt the application.

Protect Hidden VariablesCountermeasures for this attack include:

  • Effective input field filtering. Input fields should be filtered to remove all characters that might be a part of an input injection. Which characters are removed will depend upon the types of software used by the application.
  • Application firewall. Network firewalls inspect only the source and destination addresses and the port numbers, but not the contents of network packets. Application firewalls examine the contents of packets and block packets containing input attack code and other unwanted data.
  • Variable integrity checking. If you application uses values in hidden fields to communicate parameters from page to page, you need to consider adding a variable that is a computed hash of other variables. Make sure your algorithm for hashing your hidden variables is not easily guessed – or consider using encryption in addition to hashing. When each page begins to process its variables, compute the hash again and compare it to the hash value variable. If the values are different, you know that your variables have been tampered with and you can exit gracefully after logging the incident.
  • Application vulnerability scanning. Organizations that develop their own applications for online use should scan those applications for input attack vulnerabilities, in order to identify vulnerabilities prior to their being discovered and exploited by outsiders.

These countermeasures lower the risk of parameter tampering by making the application more robust and/or protected from input attacks.

Countermeasures for input injection attacks.

Countermeasures for web application input attacks

Bookmark This (opens in new window)

An input attack is a malicious attack on an application where the attacker is inputting data in an attempt to disrupt the application. Two of the most well-known input attacks are buffer overflow and script injection.

Countermeasures for these include:

  • Effective input field filtering. Input fields should be filtered to remove all characters that might be a part of an input injection. Which characters are removed will depend upon the types of software used by the application.
  • Application firewall. Network firewalls inspect only the source and destination addresses and the port numbers, but not the contents of network packets. Application firewalls examine the contents of packets and block packets containing input attack code and other unwanted data.
  • Application vulnerability scanning. Organizations that develop their own applications for online use should scan those applications for input attack vulnerabilities, in order to identify vulnerabilities prior to their being discovered and exploited by outsiders.

These countermeasures lower the risk of input injection by making the application more robust and/or protected from input attacks.

Countermeasures for parameter tampering attacks.