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!
Wikis are a very strange animal. They break everything we know about information security, for example by allowing everyone to create and edit pages.
This presentation discusses this different philosophy of information security, presents its unique security challenges and tries to provide solutions for those.
As 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.
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.
This 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
- Connectivity to central networks and the Internet
- The human factor.
The work was presented in Hack In The Box Amsterdam in 2013: