17 March 2015

Validation

Posts relating to the category tag "validation" are listed below.

13 July 2013

New Magic Quadrant for Application Security Testing 2013

A new "magic quadrant" for application security testing has been published by Gartner.

Title header from Gartner's report ' Magic Quadrant for Application Security Testing'

Magic Quadrant for Application Security Testing by Neil MacDonald and Joseph Feiman, was published by Gartner last week on 2 July 2013. It addresses 16 suppliers whose products and services analyse and test applications for security vulnerabilities using static, dynamic and interactive testing techniques. The selection criteria required the suppliers had production products and services operational on 1st January 2013, and to have more than $2 million turnover in this business area.

The report discusses each supplier's offerings, and describes the market context referencing the convergence of capabilities due to customer requirements, increasingly complex web applications and the growth of mobile apps. Trends identified include increased provision of testing as a service, the need for comprehensive application discovery, testing of client-side code (including HTML5), the benefits of explicit framework support, integration with development life cycles, and testing of mobile and back-end interfaces. The use of these products and services as a security intelligence enabler is also discussed.

Gartner charge for the report, but two of the vendors in the "leaders" category have been very prompt and provided registration forms to obtain the report "free of charge" (here and here).

"Magic Quadrant for Application Security Testing" replaces the previous "Magic Quadrant for Dynamic Application Security Testing" and the "Magic Quadrant for Static Application Security Testing."

Posted on: 13 July 2013 at 08:30 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

25 June 2013

OWASP Top Ten 2013

The latest release of OWASP's Top Ten application security awareness document, detailing the most critical web application security risks, was announced on 12th June.

Partial view of a page from the OWASP Top 10 2013

The document is intended to be an introduction to application security risks for developers, and is freely available as a PDF and on wiki pages in English. Translations into other languages will follow as volunteers have time. It will also shortly be available as a printed booklet, available to buy at cost. The 2013 edition is:

  • A1 Injection
  • A2 Broken Authentication and Session Management
  • A3 Cross-Site Scripting (XSS)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration
  • A6 Sensitive Data Exposure
  • A7 Missing Function Level Access Control
  • A8 Cross-Site Request Forgery (CSRF)
  • A9 Using Known Vulnerable Components
  • A10 Unvalidated Redirects and Forwards

Comparing with the previous edition in 2010, there is some minor re-ordering. Otherwise "Insecure Cryptographic Storage" and "Insufficient Transport Layer Protection" have been merged into the new A6 "Sensitive Data Exposure", and "Failure to Restrict URL Access " has been broadened to A7 "Missing Function Level Access Control". Finally the new "Using Known Vulnerable Components", used to be within "Security Misconfiguration" but has been separated into a standalone named risk.

For further analysis I recommend Breaking Down the OWASP Top 10 Security Flaws for 2013 and New OWASP Top 10 Reflects Unchanged State Of Web Security.

If you reference the OWASP Top Ten, now is the time to update. The risks identified are an important first step in moving to developing secure software code. Beyond this, read the sections for developers, testers and organisations at the end of the document, but I would also recommend this pair of related documents:

Posted on: 25 June 2013 at 11:00 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

22 July 2012

Web Application Security Scanner Comparison

Testing for vulnerabilities is just one part of a wider secure software development life cycle. While manual testing has great value, the use of automated tools is necessary to assist with anything but the smallest of applications. But which tools should you use?

Images from the DAST comparison showing the ticks and crosses in a feature chart on the website sectoolmarket.com

The results of a comparison of dynamic web application vulnerability scanners has just been published by Shay Chen. 2012 Web Application Scanner Benchmark updates a similar study undertaken in 2011 and compares ten different aspects of the tools.

The analysis examined 11 commercial tools and a slightly larger number of maintained free/open source tools and provides a superb reference for anyone undertaking a selection process. The results are presented in a dozen web pages at http://sectoolmarket.com/.

Of course what matters is the coverage, false negative rate, false positive rate and the features you need for your own style of applications.

See also the comparative studies in the other papers referenced, but especially Analyzing the Accuracy and Time Costs of Web Application Security Scanners, Larry Suto, February 2010 (and discussion/responses) and the SAMATE bibliography.

Posted on: 22 July 2012 at 15:06 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

01 May 2012

OWASP London Environs AppSec Double-Bill

Next week there are two London-based Open Web Application Security Project (OWASP) events.

Photograph of two washing machines for sale in a supermarket with signs above them saying 'Mobile Phones' and 'Digital Cameras'

On Thursday 10th May, there is an Application Security One-Day Conference organised jointly with ISSA UK. It is being held at Bletchley Park from 09:45 hrs and is free to members of OWASP London, ISSA-UK and the Charities Security Forum (CSF). Prior registration is required. The presentations include:

  • ISO/IEC 27034-1 and OpenSAMM software assurance frameworks
  • Third party application analysis
  • OWASP Mobile Top Ten
  • HTML5 web security
  • Cost & business justification models for AppSec

There is also an opportunity for a guided tour of Bletchley Park to see the site of the secret British code-breaking activities during WWII and birthplace of the modern computer.

In the evening there is another OWASP event organised by OWASP Royal Holloway University of London (RHUL) at RHUL's main campus in Egham. The presentations start at 18:30 hrs and will be about:

  • Websecurify web security testing technology
  • Online habits and digital trails
  • Making security invisible for developers

There is just about time to attend both meetings for a very full and informative day.

Posted on: 01 May 2012 at 21:56 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

14 February 2012

[In]Vulnerable SDLC

Weaknesses in software security? Long-term security advocate and practitioner Eoin Keary has written an article about the weaknesses in our approach to application security.

Construction staff waiting to begin their night shift outside the new Thameslink 2000 station at Farringdon in Clerkenwell, London, UK

Eoin describes the problems with past and current approaches, and has come to believe organisations should use a structured and repeatable method for addressing security in the software development lifecycle (SDLC) encompassing:

  • Secure design
  • Developer training
  • Common module/framework design and implementation
  • Code review
  • Integrated functional/security/anti-functional testing.

He also proposes that manual efforts are used in the SDLC, and in verification activities for runtime scanning, rather than in undertaking manual penetration testing. Eoin also highlights the need for ongoing, continuous monitoring, feedback and analysis in what he terms Enterprise Security Intelligence (ESI) — maybe that is Eoin's Secret Ingredient?

Read, learn, respond and implement what will work with your own organisation's risks and culture.

Posted on: 14 February 2012 at 07:22 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

27 December 2011

Guide to HTML5 Web Security

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

An extract from a page in Michael Schmidt's document HTML5 Web Security showing how HTML5 vulnerabilities and attacks are described and illustrated in diagrammatic form

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

  • 2.2 Cross-origin resource sharing
  • 2.3 Web storage
  • 2.4 Offline web application
  • 2.5 Web messaging
  • 2.6 Custom scheme and content handlers
  • 2.7 Web sockets API
  • 2.8 Geolocation API
  • 2.9 Implicit relevant features of HTML5
    Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

Posted on: 27 December 2011 at 09:07 hrs

Comments Comments (4) | Permalink | Send Send | Post to Twitter

09 September 2011

Secure Web Application Development and Implementation

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Partial image of the title sheet from the Centre for the Protection of National Infrastructure CPNI guidance document 'Development and Implementation of Secure Web Applications', published in August 2011

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

  • Introduction to web application security
  • General aspects of web application security
  • Access handling (authentication, session management and access control)
  • Injection flaws
  • Application users and security
  • Thick client security
  • Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

Posted on: 09 September 2011 at 20:00 hrs

Comments Comments (1) | Permalink | Send Send | Post to Twitter

19 August 2011

How Old Is the Internet?

Last night, I came across evidence of the oldest web site so far known.

Partial screen capture showing the start of the customer survey - the first question says 'According to our records, on 29/12/1899 you purchased ******* Is this correct? Note the tickets were purchased online at www.*******.co.uk', with three possible answers 'Yes, No, Don't know'

I had been sent a request to complete an online customer survey and duly clicked through to the online form. Clearly I am very old, and the web site even older. I did even wonder what the data retention policy is. Or maybe there's been a slight data import issue here? Applications need data validation in more places than just inputs from humans. Data from other systems, including so-called "trusted systems" can also be prone to errors, incompatibilities and troublesome content. And some of that can also be malicious. It needs to be defined properly and then validated.

I remember one of my own projects which threw an input validation error many years after it was deployed, because the system it was integrated with changed the format of their response codes. My application was accused of being "over engineered". Well, "fail-secure" I said. And in any case, prior to development, we had tried for a long time to get a specification for what codes to expect, but no-one had an answer, and we had to make some assumptions and put bounds on what was reasonable. It worked for 4 years, and was logging, but I admit it could have done with sending an alert on detection of an invalid response.

While the example of the customer survey above is just mildly amusing, it might hint at poor secure development practices — just the sort of thing malicious users might ponder how to exploit. I don't think there's any significant risk here, especially since the date appeared to be the only custom data in the survey.

Posted on: 19 August 2011 at 08:13 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

03 May 2011

Microsoft SDL Process Guidance Update 5.1

Microsoft has released their annual update to the Security Development Lifecycle (SDL) Process Guidance.

Photograph of a high barred access gate with signs saying 'Caution - Anti-climb Paint', 'Warning - These Premises Are Protected by...' and an observation mirror mounted on a wall in the background

SDL 5.1 includes several new, updated and promoted controls which probably reflect better more typical design and coding faults. For example in Phase 2 - Design, these have been added:

  • Mitigate against Cross-Site Scripting (XSS).
  • Apply no-open X-Download-Options HTTP header to user-supplied downloadable files.

In security controls for cryptography:

  • Provide support for certificate revocation.
  • Limit lifetimes for symmetric keys and asymmetric keys without associated certificates.
  • Support cryptographically secure versions of SSL (must not support SSL v2).
  • Use cryptographic certificates reasonably and choose reasonable certificate validity periods.

During Phase 3 - Implementation, the following requirements have been updated:

  • Use minimum code generation suite and libraries.
  • Compile native code with /GS compiler.
  • Use secure methods to access databases.

And still in Implementation, the following have been added/promoted:

  • Do not use Microsoft Visual Basic 6 to build products.
  • Ensure that regular expressions must not execute in exponential time.
  • Harden or disable XML entity resolution.
  • Use safe integer arithmetic for memory allocation for new code.
  • Use secure cookie over HTTPS.
  • AllowPartiallyTrustedCallersAttribute (APTCA) review.
  • Mitigate against cross-site request forgery (CSRF).
  • Load DLLs securely.
  • Minimum ATL Version and Secure COM Coding Requirements.
  • Reflection and authentication relay defense.
  • Sample code should be SDL compliant.
  • Internet Explorer 8 MIME handling: Sniffing OPT-OUT.
  • Safe redirect, online only.
  • Comply with minimal Standard Annotation Language (SAL) code annotation recommendations
  • Use HeapSetInformation.
  • COM best practices.
  • Restrict database permissions.
  • Use Transport Layer encryption securely.

And finally in Phase 4 - Verification:

  • File parsing.
  • Network fuzzing.
  • Binary analysis.

There are also some changes to the SDL-Agile Requirements.

So, quite a significant update really, with many good recommendations being added or improved upon. Whatever your programming language, it is worth cross-checking these items with your own coding standards.

Posted on: 03 May 2011 at 08:43 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

22 April 2011

State of Software Security Report Volume 3

The third semi-annual "State of Software Security Report - The Intractable Problem of Insecure Software" has been issued by Veracode (see my previous comments on volume 1 and volume 2).

Partial view of one of the figures in Veracode's report State of Software Security - Volume 3 Volume 3 provides further insight into the results of static binary, dynamic, and manual security testing of almost 5,000 applications over the last 18 months from Veracode's wide client base. The data covers both web and non-web application code in the most common programming languages: C/C++, ColdFusion, Java, .NET and PHP.

This report provides even more data on the types of vulnerabilities found and further comparison between applications by industry sector, company type, purpose, supplier type and time to acceptable quality. There is a wealth of statistics which will be useful to anyone looking to reduce software vulnerabilities including developers, testers and those in the information security industry. I'm particularly impressed by the thought that has gone into the design of the data-rich charts and the honesty about whether trends are statistically significant.

One aspect mentioned is that newer applications tested on first time submission are not much better than older ones (in this case "older" means "a year or so ago"). The reasons suggested are either lack of secure development practices, or such practices were performed but inadequately. But I wonder if this may be the result of Veracode's customers beginning to work backwards through their legacy applications, to assess and thus rank them for remediation effort? Therefore, these legacy applications will not have had the same degree of care and attention as perhaps more recently developed software.

The mine of information presented over 50 pages also discusses the relatively low level of security knowledge of developers, and the need to provide better awareness and training. But a new section in this report attempts to examine the remediation efforts. I really appreciate the effort that has gone into this and the presentation of so much data analysis. We have to thank Veracode's customers for allowing their data to be included in this aggregated data.

The report also discusses how there is a growing usage of third-party risk assessments, where the software is assessed independently using multiple testing techniques. In some sectors, software suppliers are increasingly being held accountable for the security quality of the applications they produce. I think that is a good thing.

While there is a comparison of different sectors, I wonder if it will be possible to delve greater into some details in future? For example, some large providers of outsourced development are also active in the software security space, and have their own products for static & dynamic security testing, and even provide software security consultancy services. Do those companies take their own medicine? Do they apply the knowledge and tools they offer in another part of their business in their own software development services? We probably won't find out any time soon, but it would be fascinating to know.

The report's data suggests web applications are still plagued by vulnerabilities such as cross-site scripting (XSS), information leakage and injection (SQL injection as CRLF injection). Meanwhile the most frequently found issues for non-web applications are buffer overflow, error handling and potential backdoors. Cryptographic issues are also very common. The majority of applications tested suffer from these well-known defects, and all of which are well documented and have a range of methods to solve them.

Good reading for the beach this weekend!

Posted on: 22 April 2011 at 12:45 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Validation : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by 23.23.53.177 on Thursday, 28 May 2015 at 02:36 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk