Sorting out web automation attacks

If anything makes  web applications security different, and more interesting, than traditional information security, those are threats to the application logic, i.e. attacks that abuse legitimate functionality. Such attacks often raise legal and ethical questions: if this is legitimate functionality, can it be an attack? Ethical questions a side, there is no question that click fraud, scraping and comment spam cause real pain and financial damage to web site owners.

The new OWASP automated threat handbook tries to sort out this field and define an ontology for web automation attacks and for countermeasures.

My own presentation on the topic takes a different approach: there is no real dividing line between valid and malicious automation. It is a continuum. I scored each such automation technique for “obviousness”, i.e. how clear it would be that this is automated and not and for maliciousness.  Based on the scores I split the techniques into obviously malicious, accepted and borderline. So for example, given a 1-5 scale (1 being not obvious/not malicious, 5 being obvious/malicious):

  • “Auction sniping” gets 2 for obviousness and 3 for maliciousness – which makes it borderline.
  • “Web spam” 3 for obviousness and 4 for maliciousness – the extra points puts it in the malicious category.
  • At the edges, Blind SQL injection gets 5 and 5 (so it is extra malicious) while comparative shopping gets 1 for maliciousness as it became a standard in the industry. Which does not imply the “attacked” web site is not negatively impacted.

Read the presentation to get the scored for all of them and learn what “Queue Jumping”, “auction sniping” and “web spam” are!

The WAF Guidebook: Secure Development Life Cycle

(This is the first chapter of a Web Application Firewall Guidebook to be published in the next few posts)

Before getting into web application firewalls let’s review the problem they solve and alternative solutions. As web application security is essentially a software quality problem, resolving it require fixing the way we develop, deploy and operate software. This process is usually referred to as the software development life cycle, or SDLC for short. The security aspects of the SDLC process are called Secure Development Life Cycle, which confusingly has the same abbreviation: SDLC.

Ideally, fixing the security of web applications should be done at all SDLC stages as vulnerabilities are introduced in all stage. While it is better and potentially cheaper to fix issues early on, no quality assurance is perfect and bugs are carried on to following SDLC stages.

Since there is a cost for implementing security in any stage of the SDLC, when allocating resources we need to make a choice as to where to invest and how much. If any of the solutions outlined below was a silver bullet, the decisions would have been easier, however this is not the case. Is it better to invest a lot in educating developers and having a more secure code but neglect to test or protect the code in the operational environment? probably not, after all no code is vulnerability free no matter how good the developers were. On the other hand, should we only deploy a real time operational control such as a web application firewall? It would be unnerving to release buggy software no matter what automated solutions are there to protect it.

Let’s review the available application security solutions at every stage of the SDLC: Continue reading

Google Apps Security

google-apps-logo-iconsAs Google Apps become more popular in organizations, the security issue takes central stage. Interestingly, the technical aspects are the least of your worries, after all Google’s application security team is as good as they get. Many of the challenges are not technical in nature but rather legal and privacy issues.

Among the issues discussed in the presentation:

  • Information ownership
  • Illegal information storage
  • Privacy issues
  • Application security
  • Authentication management
  • Administrator access

You can also find a video of the presentation here.

RESTful services, web security blind spot

As a light weight alternative to web services, RESTful services are fast becoming a leading technology for developing mobile applications and web 2.0 sites.

At first glance, RESTful web services seem very different than web services and suspiciously similar to regular web technology. The similarity of RESTful web services to regular web leads to the notion that RESTful web services can be tested and secured in the same way.

However, this is a misconception. RESTful services share many of the security challenges of other web services technologies, but lack a formal structure to compensate for that. Specifically, testing RESTful web services is challenging as common pen testing attack surface detection and fuzzing techniques do not work.

This presentation presents the challenges and possible solutions for assessing RESTful web services security. Topics include :

  • RESTful web services and their use
  • The complexities in protecting RESTful web services and common attack vectors specific to them.
  • The challenges of security testing for RESTful services
  • Innovative approaches for automated testing of RESTful services.

You can download the presentation here or watch the video recorded at Source Seattle in September 2012 here.

“Who can hack a power plug?”, the info security risks in electric cars charging

charge-stationThis research presents a case study of IoT security. Deviating from the usual suspects, it focuses on an emerging IoT node: a public electric car charging station. Since electric car batteries are limited in capacity and since charging takes time, such curb side power plugs are essential to enable the electric cars revolution.

Such charging stations need to authenticate the customer, using smart cards for example, handle payments, communicate to the driver, on his phone, the charge status and in the future balance power demand in the locality of the charging station. As a result, this is very much a smart power plug: essentially a computer lying there on the curb side.

The presentation introduces electric car charging stations and then discusses and brings example of key potential vulnerability areas:

  • Physical access
  • Short range communications
  • Encryption
  • Connectivity to central networks and the Internet
  • The human factor.

The work was presented in Hack In The Box Amsterdam in 2013:

The closest airport to my house is in Damascus

I live in a war zone. The Syrian border is just 15 miles from my home and a horrible civil happens there. Less than one mile from hermon_from_emek_qedeshmy house is another border which I have never crossed dividing me from people I may never meet. But when I jog along this border, with the wonderful view below, listening to the birds sing, it all seems quite unreal.

Is the quietness deceptive? Am I secure? Maybe this perspective enables me to understand better than my fellow information security folks that nothing is really secure. Security is relative. One can be more secure than his neighbor, or more secure than he was last year, but nothing, never, is just secure.

The most obvious outcome is that my interest has always been protecting rather than breaking. It is just not that much fun to break things that are inevitably breakable.