31 March 2014

Preventative

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

11 October 2013

Application-Layer Denial of Service Attacks

We often hear about infrastructure denial of service (DoS) attacks, but traditionally there has not been much data available on application-layer DoS.

One of the charts from the Q2 2013 DDos Attack Report

The Prolexic Distributed DoS (DDos) attack reports includes a comprehensive analysis of data from their own networks. Application-layer attacks against their clients accounted for 25% of attacks, with the remainder against infrastructure (OSI layers 3 and 4). For the infrastructure attacks, SYN floods accounted for almost half of all attacks (the report's text says 31.22 of infrastructure, but the data in Figure 3 suggests it is 31.22 of all attacks).

The number of attacks has risen by a third, but it is not clear whether this is due to the company having more clients, or because the were more attacks against each client. The points I found of most interest:

  • Compromised web servers are now the preferred method of attack, not a botnet of home PCs
  • An average attacks lasts less than two days
  • The average bandwidth is almost 50 Gbps, but half are less than 5Gbps, and a fifth are less than 1Gbps
  • GET floods account for the majority of application-layer DDoS attacks
  • Many low-volume attacks are easy to launch without significant skill
  • Amplification attacks where the attacker spoofs their identity to be that of the ultimate target and are sent to intermediary victim servers, are favoured due to the additional impact and source obfuscation.

The reports are free to download after registration.

See also previous posts on Denial of Service Attack Defences and Distributed Denial of Service Attacks.

Posted on: 11 October 2013 at 08:14 hrs

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

09 October 2013

Microsoft SDL in the US Financial Services Sector

Microsoft has published a survey commissioned from The Edison Group which examines application development security in the US financial services sector.

Title page from the paper 'Microsoft Security Development Lifecycle Adoption: Why and How'

Microsoft Security Development Lifecycle Adoption: Why and How examines the adoption of Microsoft's process-driven Security Development Lifecycle (SDL) in this sector, the approaches taken, integration methods and looks at the benefits realised. The researchers interviewed a number of companies that use MS SDL.

I found the survey's most useful parts are the list of adopters' best practices and lessons learned. The case studies are perhaps too short to be of any significance, and the second one referring to using SDL for open source development almost seems to have been included to put the idea of using open source tools down, rather than contributing to the "why and how" of the report's title. Unnecessary and wasted space in the document.

Read, compare and contrast. Then consider how these types of things might work within your own organisation and with particular teams.

The paper also refers to the previously mentioned BITS Software Assurance Framework from the Financial Services Roundtable, and Part 1 (Overview and Concepts) of ISO 27034, but not other sources.

Posted on: 09 October 2013 at 08:52 hrs

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

24 September 2013

OWASP ASVS for Web Applications 2013 Beta Release

OWASP's less well known, but immensely useful, Application Security Verification Standard (ASVS) for web applications has been updated and a beta version was released just prior to AppSec EU last month.

Diagram from the OWASP ASVS Web Application Standard 2013 showing the four different web application security verification levels

The ASVS Web Application Standard 2013 defines a set of technical controls for applications that should be verified as part of security testing processes. They are primarily application controls but also include relevant ones in the host environment. The document describes three use cases — for application certification, for alignment of testing methodology and for selection of external suppliers.

The number of classes requirements has been expanded to 13, and now covers:

  • Authentication
  • Session management
  • Access control
  • Input validation
  • Cryptography at rest
  • Error handling and logging
  • Data protection
  • Communications
  • HTTP
  • Malicious controls
  • Business logic
  • Files and resources
  • Mobile.

Each class includes around 10-20 specific requirements. The new sections, and re-allocation of some requirements means that the numbering has changed significantly. The cross-referencing will be important for those already using the ASVS Web Application Standard 2009.

Not all the requirements need to be achieved for every application. The choice can clearly be organisation-specific, based on its own risk assessment, but the document describes four levels of verification, each successive level increasing the number of mandatory requirements.

The project team, primarily Andrew van der Stock, Sahba Kazerooni, Daniel Cuthbert, and Krishna Raja, are working on gathering feedback from the community, creating use-case examples, and mapping to other OWASP projects such as the upcoming new Developer and Testing Guides.

Please help by providing your own ideas to finalise the beta release via the project's mailing list.

Posted on: 24 September 2013 at 08:34 hrs

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

20 September 2013

Safety, Security and Survivability

I have never been certain about precisely when to use the term "safety" instead of "security".

Photograph of North Bastle, Gatehouse, a fortified farmhouse built around 1600 to help stabilise the Scottish/English border - the steps and platform on the front are more recent additions

One of the advantages of going along to professional, developer and vendor events is the opportunity to meet new people, and learn about new ideas or gain additional insight into existing issues. At one recent event in London, I asked someone about the difference between safety and security. He kindly pointed me in the direction of a technical note, published by the Software Engineering Institute of Carnegie Mellon University.

Common Concepts Underlying Safety, Security, and Survivability Engineering (2003) defines the fundamental concepts of each term and provides comparative models. In summary:

  • Safety is the the degree to which accidental harm is prevented, detected, and reacted to
  • Security the degree to which malicious harm is prevented, detected, and reacted to
  • Survivability is the degree to which both accidental and malicious harm to essential services is prevented, detected, and reacted to.

The quality factors for survivability are prevention, detection and reaction (aka resistance, recognition and recovery).

I will need to consider my use of these terms.

Posted on: 20 September 2013 at 08:20 hrs

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

06 September 2013

AppSecEU Research 2013 Part 3

... Continued from Part 2. As I was speaking in the afternoon, I did not attend quite so many presentations on this second day of AppSecEU 2013.

Photograph taken during OWASP AppSec EU Research 2013 showing one of the conference rooms

For the first hour and half, I attended the OWASP Project Leaders' Workshop, organised by Simon Bennetts, OWASP ZAP Project leader, and Abraham Aranguren, OWASP OWTF Project leader. The meeting was used to share ideas and problems, relating to managing projects, engaging and supporting contributors, code/file repositories, sharing and coordinating approaches. I found the meeting very useful and it was good to meet some active contributors face-to-face.

Photograph taken during OWASP AppSec EU Research 2013 showing Erlend Oftedal presenting on securing a modern JavaScript based single page web application

Erlend Oftedal described how logic is shifting from the server into JavaScript, and how this approach is used in single web page applications where the JavaScript loads data and templates, and allows navigation without page reload. He discussed common issues on the client, and also the backed server resources such as promiscuous web services. He presented q number of recommendations for security such applications. [video]

I took a short break to meet with other delegates and also do a final run-through check of my presentation for the afternoon.

Photograph taken during OWASP AppSec EU Research 2013 showing Stefano Di Paula

Just prior to lunch, I went back to the main auditorium to listen to Stefano Di Paula discussing anti-clickjacking measures, and problems with common JavaScript libraries such as jQuery and YUI. Stefano's deep knowledge on these subjects shone through and lead to some very specific questions from the audience. [video]

After lunch the theme of click-jacking protection continued with a presentation by Martin Johns. He presented the common approaches used to today, pros and cons of these, and discussed alternative techniques. He also outlined another protection approach which he his working on with others, which was debated with other knowledgeable delegates in the audience. [video]

Photograph taken during OWASP AppSec EU Research 2013 showing a view of the Hamburg skyline from the conference venue

Mid-way through the afternoon, I presented my own talk about OWASP AppSensor - In Theory, In Practice and In Print. I provided a brief overview of application-specific attack detection and real-time response, and discussed the new guidebook currently in review and provided a link to the latest version. I then went on to demonstrate how it is possible to apply AppSensor-like capabilities to a third-party application with minimal changes to application, but yet will achieve a significant degree of protection. [video]

Immediately afterwards I stayed in the same conference room to hear Sahba Kazerooni outline the new draft OWASP Application Security Verification Standard v2. I provided some feedback on an earlier draft and it was good to hear how the beta release has moved forwards. This will be a large improvement in this already highly mature project and the team are looking for feedback before the final version is released. [video]

The final keynote was provided by Prof Dieter Gollman of TU Hamburg who discussed a generalised view of access control for web systems. [video]

Photograph taken during OWASP AppSec EU Research 2013 showing the organising team during the closing ceremony

In the closing ceremony Dirk Wetter presented awards for the capture the flag competition, and passed on thanks to all the sponsors, volunteers and OWASP staff who had helped make the conference happen. Sarah Baso stood up to provide thanks to Dirk, and his family, for all their input over the last year and to provide a small gift in OWASP's appreciation. [video]

It was truly a very useful and well organised conference, and despite having some worries about the split-floor venue, really that didn't seem to matter at all. It was a fantastic knowledge-rich event and I am so pleased I attended. The recordings of all the other sessions I was unable to attend are also available online, free of charge and without registration, and the slide decks will be available shortly too.

If you want to attend something similar, the next global ApSec conferences are in Latin America (Lima, Peru) in October and North America (New York, USA) in November.

The next AppSecEU event will be held in Cambridge, UK, on 23-26 June 2014.

Posted on: 06 September 2013 at 10:32 hrs

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

06 September 2013

AppSecEU Research 2013 Part 2

... Continued from Part 1. As usual with these types of events, in AppSecEU 2013 I had already missed a number of talks on other tracks on fascinating and useful topics by great presenters.

Photograph taken during OWASP AppSec EU Research 2013 showing Roberto Suggi Liverani presenting

I continued the first day by listening to Roberto Suggi Liverani discuss using browser automation frameworks and web proxy APIs to assist the assessment of client-side applications. He demonstrated the use of an extension for Burp Suite called the CSJ extension that combines the use of Crawljax JUnit and Selenium web driver. [video]

Photograph taken during OWASP AppSec EU Research 2013 showing a view of Hamburg taken from the conference venue

With the unfortunate absence of Gareth Heyes, Erlend Oftedal stepped in to provide a presentation about implementing and testing RESTful web services. He described common difficulties such as session timeout, third party authentication, anti CSRF tokens, cryptography, access control, replay attacks, and XML attacks. He presented a series of recommendations to avoid common pitfalls. [video]

Photograph taken during OWASP AppSec EU Research 2013 showing a flip chart used during one of the Open Source Showcase discussions

Throughout both conference days an open source security showcase was running, with each project having a dedicated room and expert available for discussion, assistance and hands-on demonstration. These proved to be very popular due to the quality of the topics and facilitators.

Florian Stahl and Johannes Stroeher jointly presented a methodical approach for texting mobile applications that included information gathering, threat modelling, enumeration, code and component review and dynamic testing. [video]

Photograph taken during OWASP AppSec EU Research 2013 of one of the break-out areas

Two locations were provided for refreshment and food breaks, one on each conference level. These were heavily used by the delegates and were also where there was an opportunity to meet with the various conference sponsors and other supporters.

To conclude the first day, I listened to the final talk on the HackPra track by the track's enigmatic co-organiser Mario Heiderich. He discussed XSS attacks and how it is normally possible to bypass any form of filtering, especially when there are bugs in the web browsers themselves, unless strict whitelist approach is utilised. He reiterated that it is important to be extremely wary of user-generated CSS. [video]

On the Thursday evening, we were treated to the conference dinner on board the museum cargo ship Cap San Diego. And some beers. Pre-dinner drinks were available on the deck, dinner was on two levels within the extensive cargo hold, and there was an opportunity to have a guided tour of the vessel afterwards with one of the former sailors.

Photograph taken during OWASP AppSec EU Research 2013

Continues in Part 3...

Posted on: 06 September 2013 at 10:31 hrs

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

06 September 2013

AppSecEU Research 2013 Part 1

I have been unable to make time to write up my notes from AppSecEU 2013 until today. Apologies for the delay, but I hope they are still of use. I have included links to the high-resolution videos of each talk mentioned which were published immediately after the event.

Photograph taken during OWASP AppSec EU Research 2013 showing the evening event held at Hamburg City Beach Club

The schedule had looked very enticing, and I had some ideas about what I would listen to and participate in. I arrived in Hamburg late on Wednesday afternoon just as the training courses were ending for the day. It seems the training had been a huge success with 120 attendees. After a quick refresh, I headed down to the Hamburg City Beach Club where OWASP had arranged a place for trainees, trainers, conference delegates, speakers and organisers to meet, network and socialise. It seems that apart from a real working port, Hamburg also has a sandy beach. It was a good place to catch up with friends, colleagues and a few new contacts, and have some beers.

On Thursday morning, the conference began with a welcome from Dirk Wetter, Conference Chair for the event. He welcomed the 400 delegates and explained arrangements, the layout of the split-level conference (on floor levels -2 and +23), and some special tips about not inadvertently activating the fire detection systems.

Photograph taken during OWASP AppSec EU Research 2013 showing Angela Sasse giving the conference keynote

The first keynote, provided by Angela Sasse, was a brilliant start to the conference. Angela described how software designers can make a huge difference to security by not trying to force users to change their behaviour. She suggested a top ten list of why users don't follow security advice, and concluded that designers must respect users time and effort, since complexity is the enemy. As an example she used the example of authentication where the objective should be "012": zero effort, one step, two factor. She finished here presentation with the suggestion that "Security measures that waste users' time" should be considered for inclusion in the OWASP Top Ten Web Application Security Risks. [video]

PHotograph taken during OWASP AppSec EU Research 2013 showing Michael Coates and Sarah Baso from OWASP

Following this, the Michael Coates, chair of the OWASP Board and Sarah Baso, Executive Director, provided an introduction to OWASP and how volunteering adds value to the community, the individuals themselves and their employers. Everything OWASP produces is free and open. It currently has 198 local chapters in 140 countries, with 36,000 mailing list participants. It is referenced by scores of government and industry standards, guidance and codes of practice. Sarah went on to describe current initiatives, described the sources of income and expenses and announced the candidates for this year's board elections. She also explained there would be an OWASP Project Leaders' workshop the following day first thing in the morning. [video]

Jörg Schwenk provided the second keynote on the topic of cryptography in web applications. He discussed a number of misconceptions and why for example signing and encrypting cookies do not help. [video]

Photograph taken during OWASP AppSec EU Research 2013 showing Michael Orru' presenting inter protocol exploitation

After the first break of the day, I joined the HackPra Track to hear Michele Orru', co-maintainer of the BeEF project, explain how web vulnerabilities can be used to directly exploit other protocols such as IMAP, SMTP, POP, SIP and IRC using just HTTP requests. Strange but true.[video]

Photograph taken during OWASP AppSec EU Research 2013 showing Paul Stone presenting Precision Timing

Paul Stone described the previously fixed browser CSS history attacks and went on to explain and demonstrate how it is possible to use the Window.requestAnimationFrame() method in a timing attack to determine the contents of pages by examining the source code pixel-by-pixel. Not only did Paul provide a very clear explanation of the method, he illustrated how the attack was optimised in a series of incremental steps to increase confidence in the results and speed up the determination of textual content. He demonstrated how it was possible to extract credentials included in the source code of a page from another domain for example. [video]

Photograph taken during OWASP AppSec EU Research 2013 showing Nicholas Grégoire

After the extensive buffet lunch, I listed to Nicholas Grégoire speaking about tips and tricks for those who use the HTML proxy Burp Suite Pro. He discussed visualisation of XML and AMF data and extensions for JSON and JavaScript, GUI navigation, contextual buttons, hot keys, history sorting, custom payloads, managing state, the curlit extension, custom iterators, and using Burp with mobile devices. [video]

Continues in Part 2...

Posted on: 06 September 2013 at 10:30 hrs

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

09 August 2013

Looking Forward to AppSec EU 2013 - Less Than Two Weeks Away

OWASP AppSec EU 2013 is less than a fortnight away, in the beautiful city of Hamburg in northern Germany. Not long now.

Partial screen capture of the conference schedule for the second day of OWASP AppSec EU 2013 in Hamburg, Germany 20-23 August 2013

There are two days of application security training courses on Tuesday 20th and Wednesday 21st August, with a few places still available on some courses. Also on the 21st there is an Open Software Assurance Maturity Model (SAMM) workshop, open to anyone who would like to attend and is free of charge. Unfortunately I am probably not going to be able to attend the workshop due to a prior work commitment, and I will be arriving in Hamburg later in the afternoon

The conference committee has arranged a very impressive programme On the first day of the conference, Thursday 22nd, I am very tempted to just attend the HackPra Allstars event all day, but may settle on attending:

  • Busting The Myth of Dancing Pigs: Angela's Top 10 List of Reasons Why Users Bypass Security Measures, Angela Sasse
  • WebSensor - Sensing the Web with Community Collectors, Christian Bockermann
  • Cryptography in Web Security: Stupid, Broken, and maybe Working?, Jörg Schwenk
  • Rooting your internals: Inter-Protocol Exploitation, Custom Shellcode and BeEF, Michele Orrú
  • Precision Timing - Attacking Browser Privacy with SVG and CSS, Paul Stone
  • Burp Pro - Real-Life Tips and Tricks, Nicolas Grégoire
  • ThreadFix: The Open Source Software Vulnerability Management Platform, Dan Cornell
  • Augmented Reality in your Web Proxy, Roberto Suggi Liverani
  • XSS Horror Show, Gareth Heyes
  • Security Testing Guidelines for Mobile Apps, Florian Stahl and Johannes Stroeher
  • Cracking and Analysis of the Mobile Application Source Code, Sreenarayan Ashokkumar

And that's missing two-third of the parallel track presentations. There are too many good talks to attend. On the second day, Friday 23rd, I think I will go to:

  • Secure all the Things: Fiction from the Web's Immediate Future, Thomas Roessler
  • WS-Attacker, Christian Mainka and Juraj Somorovsky
  • Securing a Modern JavaScript Based Single Page Web Application, Erlend Oftedal
  • Insane in the IFRAME -- The Case for Client-Side HTML Sanitization, David Ross
  • Javascript Libraries (in)security: A Showcase of Reckless Uses and Unwitting Misuses, Stefano Di Paola
  • Clickjacking Protection Under Non-trivial Circumstances, Sebastian Lekies and Ben Stock
  • Origin Policy Enforcement in Modern Browsers, Frederik Braun
  • OWASP AppSensor – In Theory, In Practice and In Print, myself!
  • Sandboxing Javascript, Steven Van Acker, Lieven Desmet and Nick Nikiforakis
  • Access Control of the Web - The Web of Access Control, Dieter Gollmann

I don't think I will be able to see all the other talks I want to; but will catch up on the videos afterwards.

I am currently writing my OWASP AppSensor presentation for the 15:15 hrs session on Friday 23rd. I'll also have a copy of OWASP Cornucopia with me, if you want to take a look. See you there.

Posted on: 09 August 2013 at 18:04 hrs

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

02 July 2013

Time to Review/Implement Content Security Policy v1.0

Content Security Policy v1.0 is now (mostly) supported by Firefox (23+) and Chrome (25+). There is also partial support in Internet Explorer (10+).

Photograph of a sculture at Tate Modern, London, formed from hanging clear and smoked glass plates in a room with a blue line drawn around the wall

Content Security Policy is an HTTP header set by the server and enforced by the web browser (client) as a defence against cross-site scripting vulnerabilities. The experimental headers X-Content-Security-Policy and should now be replaced by the standard Content-Security-Policy.

The announcement by Mozilla regarding support for v1.0 in Firefox provided a good overview of recent changes and links to further information resources.

The steps I would recommend to introduce Content Security Policy (CSP) are:

  1. Choose one pilot web application and a single functional area with greater security assurance requirements (e.g. payment, checkout, order submission, authentication)
  2. Create a change request for deployment to production and assess the risks
  3. Attempt to remove all inline JavaScript, all inline styles and as much third-party content as possible from the functional area
  4. Create an initial Content-Security-Policy header in development, test locally and apply to staging/test systems
  5. Undertake existing unit tests for the functional area using the latest, recent and legacy web browsers
  6. Make changes to code and/or the policy to determine what can be achieved
  7. Build a mechanism to collect the violation reports, ensuring all data is treated as untrusted and is correctly encoded when utilised, and add a report-uri directive to the header to verify the mechanism
  8. In production, add the directives as a Content-Security-Policy-Report-Only header to the functional area (i.e. not as a Content-Security-Policy header)
  9. Monitor and assess the violation reports
  10. Adjust the policy as necessary and re-test, and re-deploy
  11. Once approved, change the header from Content-Security-Policy-Report-Only to an enforced Content-Security-Policy header for a test group of users
  12. Monitor and update the policy as necessary, and re-test/re-deploy
  13. Gradually extend to all users
  14. Update coding standards so that future development is compatible with the CSP
  15. Repeat for other functional areas
  16. Apply CSP policies to the remainder of the web application (with differing policies as necessary).

This blog's CSP header states the web server wishes the page only loads resources from its own origin over TLS, without frame embedding, but modify the style-src directive to allow inline styles. Thus no unsafe use of inline scripting or eval are disallowed. Also, a URL is specified for CSP violation reports. The header is:

default-src https: 'self'; frame-src 'none'; style-src 'self' 'unsafe-inline'; report-uri https://www.clerkendweller.com/report-csp.php

I have also noticed some inconsistencies in this inline styles aspect between web browsers, and also in the use of the frame-src directive. It is expected these anomalies will disappear as use of the header broadens and deployment matures. As usual it is necessary to test the use of the header across multiple browser types and versions. There also seems to be an issue with some bookmarking tools and browser extensions causes false positive reports, so use of the report-uri directive can be somewhat noisy in public parts of web applications.

Content Security Policy v1.1 is now also in progress, but do not let this on-going work delay implementation of v1.0 now.

Posted on: 02 July 2013 at 18:55 hrs

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

11 June 2013

Wish List for Security of Outsourced Payment Card Forms/Pages

The PCI DSS E-commerce Guidelines v2 were a welcome update to the previous version of the document.

Photograph taken during Muse's performance at Arsenal's Emirates Stadium in June 2013 showing the projected backdrop

One of the new aspects included in the revised guidance was a discussion of the most common e-commerce implementation models (section 3.4) and what responsibilities the merchant and other parties have (section 3.5) under PCI DSS. The models discussed are:

  • Merchant-managed e-commerce implementations
    • Proprietary/custom (bespoke) developed shopping cart/payment application
    • Commercial shopping cart/payment application (typically PA-DSS validated)
  • Shared-management e-commerce implementations
    • Third-party embedded application programming interfaces (APIs) with direct post
    • An inline frame (or "iFrame") that allows a payment form hosted by a third party to be visually embedded within the merchant's page(s), sometimes also including other intermediaries
    • Customer redirection to a third-party hosted page for payment entry
  • Wholly outsourced e-commerce implementations.

While some merchants believe they are "wholly outsourced" already, the definitions should be read. The guidance reminds merchants they still have primary responsibility for particular PCI DSS requirements. In the case of inline frame and hosted payment page approaches, this includes for example securing the web page(s) containing the iFrame code and redirection code and/or function(s) respectively.

During a recent exercise I was involved with, to identify security requirements using the OWASP Cornucopia Ecommerce Website Edition card game, a merchant's payment page hosted by a payment services provider was assessed. The process highlighted additional information security risks than those already mentioned in the PCI DSS information supplement. These related to aspects the merchant still has control over despite the outsourcing — in the exercise it was identified the merchant could customise the template of the payment service provider's page and include self-hosted (by the merchant) content referenced by the template (logo, card brand images, style sheet, and a JavaScript file). I am not sure the existing guidance is explicit enough on this aspect, and some merchants may therefore have a false sense of security, and their own risks, regarding the protection of payment cardholder data in these "semi-outsourced" (i.e. shared responsibility) situations.

If a website security assessment identified any third-party hosted content on authentication, account management or payment web pages — even JavaScript library files and web analytics code — this would normally be worthy of mention. Therefore, I think we should also take note of this merchant-controlled content appearing on payment pages/forms elsewhere, especially if the level of security assurance is different between the two (as is often the case). Merchants can outsource in an attempt to de-scope for PCI DSS and reduce the number of applicable requirements (e.g. to use SAQ A for such an online-only merchant). This may not be adequate if the merchant (its employees, contractors, systems, partners, suppliers etc) still has some control over the partially/wholly outsourced (e.g. payment service provider) hosted page/form.

Merchants should include security review and verification activities during template change processes. But regardless of PCI DSS compliance, what other technical security controls could be considered when selecting an outsourced online payment page or form? If I was a merchant, I would prefer to choose one that enables and enforces the following web application security wish list, in addition to the outsourcer's own existing PCI DSS compliance requirements:

  • Page template administration
    • Each user (e.g. each designated merchant employee) with the ability to upload or edit templates to have a unique identity, and no use of shared accounts
    • Two factor authentication for all access to the outsourcer's systems (e.g. file transfers, web administrative interfaces, web services)
    • User account access limited to a small set of merchant IP addresses
    • Encrypted connections for authentication and template upload/edit
    • Event alert to nominated address/system on template change
    • Automatic stripping of any other party hosted (i.e. non outsourcer and non merchant) content from the template with related event alerting
    • Accessible audit trail of changes
  • Payment form/page hosting
    • Only available using Transport Layer Security
    • No other party (i.e. non outsourcer and non merchant) content
    • No use or reliance on any merchant, outsourcer or other party HTTP cookies
    • X-Frame-Options HTTP header, with the value "DENY" for a page that is not framed, else with a value "ALLOW-FROM ..." that (supporting web browsers) only permits the particular form to be framed by the specific individual merchant's whitelist hostnames
    • HTTP Strict Transport Security Header
    • X-Content-Security-Policy/X-WebKit-CSP/Content-Security-Policy header with a strict policy that does not allow any content from other parties (or perhaps just some types of content from the merchant's selected hostnames
    • MIME type and character set HTTP headers correctly defined
    • Strong anti-caching HTTP headers
  • Payment form submission
    • HTTP method POST enforced, and no other method permitted
    • Only possible using Transport Layer Security.

This is a somewhat long list, but it would be interesting to know which commonly used payment outsourcers can provide this level of assistance to ecommerce merchants.

Posted on: 11 June 2013 at 17:34 hrs

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

More Entries

Preventative : Web Security, Usability and Design
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Requested by 50.17.162.174 on Sunday, 20 April 2014 at 05:39 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 http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2014 clerkendweller.com