06 November 2014

Business logic

Posts relating to the category tag "business logic" are listed below.

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

23 August 2011

Last Call for Application Defense Training at AppSec USA

Application Attack Detection & Response is the title of the one-day hands-on training course I am providing at North America's most important application security conference AppSec USA 2011 in Minneapolis, MN.

Photograph of the course handouts, team handouts, supporting materials and certificate of attendance for the course 'Application Attack Detection & Response - A Hands-on Planning Workshop' being held at OWASP AppSec USA 2011 in Minneapolis

I mentioned the course in May and since then have been preparing the course presentations, exercises, team handouts and other supporting materials. This week they are now ready and I have been through a dry-run of the whole day. The course is going to be very participatory. I will be presenting information largely based on the OWASP AppSensor Project, but half of the time will be spent on practical exercises which show how to plan a defensive strategy using application-specific intrusion detection and response.

Through the day the attendees will work in small teams building the specification for application-specific defenses of an example web application, in a tutorial-based approach. The course is technology and programming language-agnostic. In fact there is no code at all, but attendees need to be familiar with web application risks, vulnerabilities and the types of techniques attackers use to identify and exploit weaknesses. The exercises will be paper based but electronic templates will also be provided. The day will culminate in a defense simulation exercise, where the teams will score each other's defensive models against a range of attacks. 12 attacks will be selected at random from a set of pre-built scenarios with the code names:

  • Slow Discoverer
  • Yadda Yadda Yadda
  • Hit & Run
  • An Offshore Enquiry
  • Scratch 'n' Sniff
  • A Visit From A Foreign Gentleman
  • Nosey Parker
  • Coupon Chaser
  • Build Your Own Data Warehouse
  • Fraudulent Fingers
  • Teen Leaver's Delight
  • Blast From The Past
  • The Forbidden Scriptures
  • Slab Fondler's Folly
  • Yet Another Hopeless User
  • The Thirteen Problems
  • Protect and Survive

You will have to be there to discover what these are all about, but perhaps you can guess some of them?

The AppSec USA 2011 organisers have been fantastic, especially Adam Baso and Lorna Alamri of the OWASP Minneapolis-St. Paul (OWASP MSP) chapter. I am really looking forward to the week there.

I believe there are still some places left on the course, so if you want to learn about this topic and leave well-briefed to apply the techniques in your own projects or software specifications, please register as soon as possible. The course begins at 8:30 am. This is the only time this one-day course is being offered in the Americas.

On the following day (21st September), apart from one-day training courses with Robert Zakon and Sumit Siddharth, there will be an AppSensor working session, and ESAPI summit. The conference then runs on the 22nd-23rd September.

Posted on: 23 August 2011 at 07:09 hrs

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

17 June 2011

Web Services Vulnerabilities, Attacks and Defences

I'm now back in London after my talk and live demonstration at last night's well-attended OWASP Belgium chapter meeting.

Photograph of an metal & glass red public door to an office building, with a lock and push-button doorbell visible; the door has a handmade sign taped to the inside of the glass which reads 'For out of hours access, please push the bell - this will alert security immediately'

There's a good review of the evening added very promptly by Xavier Mertens (@xme) on his blog. Josh Corman (@joshcorman) provided an unexpected extra presentation towards the end of the evening where he discussed the ideas and manifesto of the rugged software initiative. I'll come back to that at a later date, but for now would like to mention the excellent talk given by Andreas Falkenberg on web services security.

He provided a carefully structured walk-through of web services technology and SOAP security features before introducing us to the idea of signature wrapping attacks, and how they might be used to exploit public web services. He also described recommended countermeasures. I won't go into the detail here, but Andreas has a paper available if you contact him. However, I did want to mention WS-Attacks.org which is a nascent project to provide information about vulnerabilities and attacks against web service standards and implementations. Many of these are unique to web services, and are in addition to the more widely-known web vulnerabilities that affect "normal" web applications.

This is a fantastic resource, and needs greater visibility amongst those responsible for designing and implementing web services.

Posted on: 17 June 2011 at 10:33 hrs

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

12 November 2010

Application Intrusion Detection and Response Planning Methodology

In my presentation at AppSec Washington DC 2010 yesterday, I described a risk-based methodology for planning the implementation of the active defensive measures described in OWASP AppSensor.

Monochrome photograph of a ship's bridge speed control telegraph, taken at the Discovery Museum, Tyne & Weir Archives and Museums, Newcastle-upon-Tyne, England

The approach is technology agnostic but certainly needs to be tailored to an organisation's own business practices, application requirements and development & acquisition processes. I described some preliminary requirements:

  • Application risk classification
  • Secure coding and deployment
  • Application security event logging.

With these available, I described a methodology to plan the implementation of AppSensor comprised of:

  • Detection point selection
    • Categorisation
    • Requirements
    • Model development
    • Optimisation
    • Code location
    • Attack analysis
  • Response action selection
    • Strategic requirements
    • Thresholds
    • Model tuning

at which point the plan should be ready to implement.

Monochrome photograph of a steam turbine's pipework and power mechanisms, taken at the Discovery Museum, Tyne & Weir Archives and Museums, Newcastle-upon-Tyne, England

The document includes some new charts and tables including:

  • Composite chart of detection point categorisations
  • Detection point inter-relationships
  • Applicability of AppSensor detection points to application risk classification
  • Detection point applicability to broad request checking and specific business logic areas
  • Detection point tuning analysis considerations
  • Example template for detection point specification
  • Example template for a schedule of response thresholds and actions

as well as a recommendation for a baseline "quick-start" implementation.

Monochrome photograph of a 'master switch' with two positions - 'on' and 'off', taken at the Discovery Museum, Tyne & Weir Archives and Museums, Newcastle-upon-Tyne, England

There are also two detection point cross-references with other documents:

The full 80-page planning workbook can be downloaded from the OWASP web site:

I am aiming to work on additional content for this document over the next few months and have also begun devising a workshop training based on the planning workbook. The course will be aimed at system owners, architects and lead developers.

Posted on: 12 November 2010 at 11:45 hrs

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

30 July 2010

Economics of Website Users' Passwords

Two great papers on web site password security were published this month. We are swamped with passwords and every daily activity is increasingly linked with an online version, which requires users to register to obtain some additional benefits. Every organisation, resource, activity and event encourages us to visit their own website and sign-up.

Poster for nightclub in Newcastle-upon-Tyne promoting the Digitalism DJs, with a link to their website on MySpace

Firstly, in Where Do [Password] Security Policies Come From?, Dinei Florêncio and Cormac Herley of Microsoft Research discuss the password policies of 75 different web sites, in an effort to determine password strength requirements with other aspects such as size of site, assets protected, number of users and frequency of attacks.

The authors' findings suggest that none of these are the key factors, and in fact some of the largest sites, most attacked and with higher-value assets have the weakest password policies. The authors suggest stronger policies exist where organisations are more insulated from the consequences of poor usability, whereas online retailers and sites that rely on advertising revenues have to compete rigorously for users and traffic. The paper also discusses how strong passwords need to be, and how this is affected also by what attack methods you are considering (e.g. online vs. offline brute-force), and whether other security controls are implemented (e.g. account lock-out).

This idea of considering the whole password environment is taken further in The Password Thicket: Technical and Market Failures in Human Authentication on the Web by Joseph Bonneau and Sören Preibusch at the Cambridge University Computing Laboratory, and presented at this year's Economics of Information Security (WEIS 2010). Their study included 150 web sites looking at password implementations. the study looked more broadly at the protective measures used— not just complexity requirements—but whether these were applied consistently across the site's functionality (e.g. registration/enrolment, log-in/authentication, password change, password reset/recovery, log-out), encryption during transmission, storage of passwords in clear text, inclusion of passwords in emails, as well as protection from brute-force attacks.

The authors found that stricter security in one area was often undermined by weaknesses in another, suggesting that a lack of standards is harming security. The paper also discusses economic interpretations, such as how deploying passwords might be being used to justify collection of marketing data, and how password insecurity can be a negative externality.

Posted on: 30 July 2010 at 08:45 hrs

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

02 July 2010

Web Site Security Basics for SMEs

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Photograph of a waste skip at the side of St John Street in Clerkenwell, London, UK, with the company's website address written boldly across it

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

  • Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
    • check backup data can read and restored periodically
    • don't forget to securely delete data from old backups when they are no longer required
  • Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
    • keep a record of the firewall configuration up-to-date
    • limit who can make changes to the firewall
  • Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
    • remove or disable all unnecessary services and other software
    • delete old, unused and backup files from the host servers
  • Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
    • restrict what each account can do as much as possible
    • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
  • Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
    • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
    • make note of any renewal dates
  • Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
    • verify who legally owns the source code, designs, database, photographs, etc.
    • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

  • Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
    • impose security standards and obligations on suppliers and partner organisations
    • keep an eye open for changes to business processes that affect data
  • Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
    • include configuration details and information about third-party services required
    • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
  • Provide information to the web site's users how to help protect themselves and their data.
    • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
    • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
  • Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
    • web server logs are a start, but customised logging is better
    • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Posted on: 02 July 2010 at 08:18 hrs

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

18 May 2010

Email Address Formats

I've mentioned input validation and knowing your data previously, but a vulnerability came up in a recent project regarding email addresses. People make many different assumptions about what might be a valid email address format.

Photograph of part of a dot-matrix printer manual page showing the patterns for a range of ASCII characters

Don't! As this recent post states, go to the source i.e. RFC 3696. Inform your developers what types and formats they should allow for each input field and how mismatches should be handled—and verify these.

The e-commerce project I had been working on had some client-side validation for the email address field in a check-out registration form and this excluded lots of valid possibilities; it was using the regular expression "\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*". This might prevent some people becoming customers. Is this classified as a security vulnerability? Normally not, but it could affect data integrity and will affect the availability to some users. But, it is an indicator of possible data validation problems elsewhere. In fact we found the server-side validation for the same form data had different constraints to the client-side (browser) checks, and yes, plenty of other input validation problems. Security problems are often related to revenue problems.

And remember, it's not just Latin characters in domain names you need to worry about now. From last week, you might begin to see unexpected problems with users who have email accounts using domains related to the United Arab Emirates, Saudi Arabia, the Russian Federation and Egypt.

Posted on: 18 May 2010 at 09:30 hrs

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

05 May 2010

Favourite Colour for Password Recovery?

The weaknesses of personal knowledge questions in password recovery schemes has been discussed previously, but a recent survey indicates you may also need to take into account the user's sex.

The survey may not have scientific rigour, but mentioning it does give me the chance to include this photograph of Alyson Shotz' sculpture Helix:

Close-up photograph of the sculpture Helix by Alyson Shotz, a aluminium and steel superstructure laminated with diachronic file, located on Euston Road, outside Sir John Soane's Holy Trinity Church opposite Great Portland Street in London during summer 2009, showing reflections of people, vehicles and the surrounding buildings in the multi-coloured facets

The survey on colour names shows that colour names are given differently by "girls and guys". I'm not sure too many girls will use "dusty teal", "blush pink" or "dusty lavender" in their "favourite colour" answer, but the listed colour names are certainly worth checking when verifying or demonstrating the strength of these personal knowledge question systems. Oh, as the survey points out, also include mis-spellings (e.g. of "fuchsia") in the testing lists of colour names. But "drop table statements" shouldn't normally be in your fuzzing list—those are for testing SQL injection.

So beware of weak password reset and recovery schemes. Sometimes they are less secure than the equivalent registration and authentication (logging in) processes.

Posted on: 05 May 2010 at 18:32 hrs

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

02 April 2010

When a Bit of Security Forethought Would Go A Long Way

Thinking of creating a mobile phone application for your business? A major privacy failure with an iPhone application has been reported on the Zero Day blog and is a useful case study.

All iPhone apps have to be approved by Apple to "protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone". But the application Quip from Addy Mobile Inc provides provided unlimited photo texting with the slogan "Why pay more for MMS? Don't you pay enough for your iPhone already?". Well, many of the application's users are paying for it now.

It seems the images (typically photos) were stored on a publicly-accessible web site, with the only access "control" being a random directory (folder) name five characters long—something that is easily iterated through to find photos and breach their customers' privacy. What makes it worse is that many of these messages and images were also turning up in public search engine results leaking sensitive information.

Partial screen capture from Google showing the search results for the query 'site:site:quiptxt.com' that include links and snippets from what were meant to be private messages

I was unable to find any privacy notice or privacy policy from the company:

Partial screen capture from Google showing no search results for the query 'site:site:quiptxt.com privacy'

The cached search results indicate the images are being stored using Amazon Web Services (AWS) S3. This is not a cloud computing specific issue. It could just as well be on a web site hosted by the company itself. The Quip web site (http://www.quiptxt.com), Quip message site (http://www.quiptxt.com) and Quip S3 image repository (http://quipimg.s3.amazonaws.com) are all currently offline. The comany issued a statement via Reddit. As the Zero Day blog says, these vulnerabilities would have been trivial to fix and protect the confidentiality of users' message text and photos. Using any of common sense, threat modelling, risk assessment or security verification should have identified the problems. I'm sure lawyers in the US will be circling. Since Apple approved the application, let's hope they are ready in case the lawyers knock on their door as well.

Addy Mobile Inc may itself be unavailable soon.

Posted on: 02 April 2010 at 11:04 hrs

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

30 March 2010

Let Down By Customer Surveys

Almost every sale, citizen enquiry and support request now seems to lead to being asked to complete an online customer survey. Almost without exception, the user experience, privacy and security of these online customer surveys are worse than the service being asked to comment on. Here are a couple of customer surveys I was asked to complete last week.

Partial screen capture of an online customer survey web page showing a browser alert message asking the user 'Do you want to view only the webpage content that was delivered securely? This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage' with buttons for More Info, Yes and No

Problems with using SSL, such as shown above, do occur but more often than not people are asked to submit personal identifiable information and other forms of personal data without the use of SSL. Bad layout, poorly designed questions, missing privacy notices and improper validation are extremely common. Many forms have mis-configured web sites that give away sensitive information about how the site and server are set up when they don't work:

Partial screen capture of an online customer survey web page showing an error message on submission of the customer feedback form stating 'There was an error processing your save please try again later.
at Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger(String Value) at Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger(Object Value) at ************.completeScorecardDependency.Save(String ButtonClicked) in D:\wwwroot\**************\feedback\completeScorecardDependency.aspx.vb:line 831 Conversion from string

And on Saturday I was given a coupon given at a shop's physical checkout to provide feedback on how they did with the chance of winning an iPod or cash for doing so. Yesterday I typed in the URL from the coupon, entered the required store code, and... that was the end of that marketing exercise:

Partial screen capture of an online customer survey web page with a trapped error message stating the server had encountered an error internal error 'which prevented it from fulfilling the request. Your session may have timed out. Try re-starting your web browser and re-enter the URL on your survey invite'

I didn't time out as the message suggested, unless you have less than 5s to answer one question. Perhaps there is only one custom error page for all server-side errors, or the wrong error page is assigned? Points for hiding internal error messages, but still a failure.

Is 3/3 customer surveys tried in the last fortnight broken just bad luck? Or does it indicate a poor standard of such efforts? One of these is an international consumer brand, another a major UK High Street retailer and the other, a medium-sized business services company. I can't quite remember the the previous customer survey to these three, but I think it may have been a salary/skill survey. That had poorly thought-out questions and although it didn't obviously fail, it did ask me to log in on submission. So I'm not sure if that meant my efforts had been saved or not.

Do all these problems and errors mean the data from other people's forms that were successfully submitted (if any) are less valid? I can imagine management decisions are being made as a result of the survey feedback (if not, why waste everyone's time?). What is the effect on data quality? It could be that some forms fail when a particular answer is selected or left blank—this could be important marketing knowledge, and if no responses include the particular option it may be incorrectly assumed no-one selected it. The management decisions will be being based on poor data.

Perhaps part of the problem is that customer surveys are often managed, operated and hosted by third parties due to the ease of implementation. But "easy" doesn't mean it meets your own organisation's standards, or general good practice. You are still accountable for the web issues and it's your organisation's reputation that will be affected detrimentally.

Good design, privacy and security impact assessments, thorough testing and verification are required like any other other addition to a web site. Analytics should be used to track survey users through forms and this data combined with server logs of access and errors generated by the web server. Prove your marketing data are valid before you use it in business decisions.

Posted on: 30 March 2010 at 09:25 hrs

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

More Entries

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

Requested by on Wednesday, 25 November 2015 at 04:09 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