Eoin & The Security

Our Traditional approach to penetration testing, even large scale global penetration testing is to perform an annual/bi-annual pen test on our web applications. Question is who said once a year is enough? Most applications undergo at least quarterly updates and changes if not to provide value for customers but to ensure the web applications are fresh and to address any (hopefully) minor bugs. Cyber attackers can perform a continuous scan on your site to detect changes (code drops) and probe such changes to assess if any vulnerability has been introduced. Why do we think it is acceptable to perform a time-limited test of an application to help ensure security when a determined attacker may spend 10-100 times longer attempting to find a suitable vulnerability. The main reasons for a one-off test per year are simply economics: Testing takes resources Resources cost money Resources are scarce Push to deploy is stronger than push to secure Organisa...

Its been a while since i posted. I've been bogged down with code reviews and training but even when you deliver training you learn something new. This is particularly true when training developers keen to learn secure development. The conversations during the course tend to be more about building than breaking.... HTTP - one side of a many sided coin So on with today's rant......many penetration testers still feel testing an application surrounds testing the HTTP requests and responses between the browser an client; Crawl the application, flag interesting parameters and fuzz using a scanner like OWASP Zap proxy or whatever...... .......We hope the scanner renders the page as a browser sees it. If it doesn't how do we know the reaction of the application is being detected. Many scanners parse HTML pretty well but when it comes to javascript/jquery/client-side-code-execution that's where they fall over. One of the hardest things to do w...

Cross Site Scripting is sill a very common web vulnerability. Generally it is used to attack clients/users. It can be used for malware upload, botnet hooking, keylogging, a payload delivery system for clickjacking and CSRF attacks and much much more, all for 6 easy payments of $9.99...sorry got carried away there :) But is is easily preventable. You dont even have to know what XSS (type 0, type 1, type 2, DOM, Stored, Reflected) is to prevent it. One pretty simple way to prevent XSS is to use the OWASP ESAPI (Enterprise Security API). A very easy tool to use/invoke. It's also managed and attended to by Chris Schmidt ....A great guy... Regardless of what it does....if there was a mandate to use it on all redisplayed external input a site could become virtually XSS free!! (all for 6 easy payments of......). It's easy to deploy.... 1. Include in JSP (Java version) 2. Invoke in JSP 3. Job done!!! We include it by <%@ page import="org.owasp.esapi.ESAPI...

"Are we secure?...." A major issue with enterprises is "are we secure?" (what does that even mean...). If you are asked by the CEO whilst sharing a lift to the 10th floor,what do you answer??? eh..em yes..er no...well sort-of..... A few important aspects in attempting to figure out "Are we secure?" from an web security standpoint are (1) How do we make sure the security of our current public facing Internet web landscape is *pretty* robust (not 100% secure)? - Test, maintain, patch, measure, observe..... (2) So how do we make sure systems in design/development are not going to introduce new risk to your business? - Security: Design, Dev,Test, Review, Deploy, Maintain, Patch. ..........So how do we track ongoing assurance efforts, prioritization of technical issues, appoint appropriate risk, track remediation, identify root cause, technology adoption weakness, mixed with securing new deployments (1) & (2) above? - Excel Spreadsheets, Memor...

This document reflects my personal opinion on the state of application security. It calls out what I see are the weaknesses of our approach as a community to addressing the issue of web [in]security. Web [in]security is a healthy and growing industry and rather than verification of issues we constantly find and are exposed to new threats without every addressing the current ones en-masse…….   A long ,long time ago we used to “ test security out ” when it came to web applications. This meant performing a time limited penetration test on a web application in the hope you could find all the existing vulnerabilities using the skills, resources and tools at your disposal….Oh, actually we still do this.. There are weaknesses to this approach and can be reflected in the current state of internet, application, cyber security. To be honest the issue of web [in]security is getting worse. Despite growth in the security industry (solutions, vendors, consultants) and the fact th...