OWASP Top 10 Application Security Risks 2017

The OWASP Top 10 for 2017 is based primarily on 11 large datasets from firms that specialise in application security, including 8 consulting companies and 3 product vendors. This data spans vulnerabilities gathered from hundreds of organisations and over 50,000 real-world applications and APIs. The Top 10 items are selected and prioritised according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact.

The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organisations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here.

A1 – Injection

Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorisation.

A2 – Broken Authentication and Session Management

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities (temporarily or permanently).

A3 – Cross-Site Scripting (XSS)

XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user supplied data using a browser API that can create JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A4 – Broken Access Control

Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorised functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

A5 – Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

A6 – Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

A7 – Insufficient Attack Protection

The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.

A8 – Cross-Site Request Forgery

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

A9 – Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defences and enable various attacks and impacts.

A10 – Under-protected APIs

Modern applications often involve rich client applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities.

IT Security Incident

IT Security Incident but no incident response capability?

This is a list of the major steps that should be performed when an IT professional believes that a serious incident has occurred and the organisation does not have an incident response capability available.

  1. Document everything. This effort includes every action that is performed, every piece of evidence, and every conversation with users, system owners, and others regarding the incident.
  2. Find a coworker who can provide assistance. Handling the incident will be much easier if two or more people work together. For example, one person can perform actions while the other documents them.
  3. Analyse the evidence to confirm that an incident has occurred. Perform additional research as necessary (e.g., Internet search engines, software documentation) to better understand the evidence. Reach out to other technical professionals within the organisation for additional help.
  4. Notify the appropriate people within the organisation. This should include the chief information officer (CIO), the head of information security, and the local security manager. Use discretion when discussing details of an incident with others; tell only the people who need to know and use communication mechanisms that are reasonably secure. (If the attacker has compromised email services, do not send emails about the incident.)
  5. Notify the National Cyber Security Centre and/or other external organisations for assistance in dealing with the incident.
  6. Stop the incident if it is still in progress. The most common way to do this is to disconnect affected systems from the network. In some cases, firewall and router configurations may need to be modified to stop network traffic that is part of an incident, such as a denial of service (DoS) attack.
  7. Preserve evidence from the incident. Make backups (preferably disk image backups, not file system backups) of affected systems. Make copies of log files that contain evidence related to the incident.
  8. Wipe out all effects of the incident. This effort includes malware infections, inappropriate materials (e.g., pirated software), Trojan horse files, and any other changes made to systems by incidents. If a system has been fully compromised, rebuild it from scratch or restore it from a known good backup.
  9. Identify and mitigate all vulnerabilities that were exploited. The incident may have occurred by taking advantage of vulnerabilities in operating systems or applications. It is critical to identify such vulnerabilities and eliminate or otherwise mitigate them so that the incident does not recur.
  10. Confirm that operations have been restored to normal. Make sure that data, applications, and other services affected by the incident have been returned to normal operations.
  11. Create a final report. This report should detail the incident handling process. It also should provide an executive summary of what happened and how a formal incident response capability would have helped to handle the situation, mitigate the risk, and limit the damage more quickly.
Apple Logo on Building

Multiple Vulnerabilities in Apple Products

Multiple vulnerabilities have been found in Apple products that could allow for arbitrary code execution

Multiple vulnerabilities uncovered in watchOS, iOS, tvOS, macOS, iCloud for Windows, and iTunes for Windows and Safari, the most severe of which could allow for arbitrary code execution. watchOS is the mobile operating system for the Apple Watch and is based on the iOS operating system. iOS is a mobile operating system for mobile devices, including the iPhone, iPad, and iPod touch. tvOS is an operating system for the fourth-generation Apple TV digital media player. macOS is Apple’s desktop and server operating system for Macintosh computers. iCloud is a cloud storage and cloud computing service from Apple. iTunes for Windows is a media player, media library, online radio broadcaster, and mobile device management application developed by Apple. Safari is a web browser available for OS X and Microsoft Windows.

Successful exploitation of the most severe of these vulnerabilities could result in arbitrary code execution within the context of the application, an attacker gaining the same privileges as the logged-on user, or the bypassing of security restrictions. Depending on the privileges associated with the user, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

There are currently no reports of these vulnerabilities being exploited in the wild.

Systems Affected;

  • watchOS Versions prior to 3.2.2
  • iOS Versions prior to 10.3.2
  • tvOS Versions prior to 10.2.1
  • macOS Versions prior to 10.12.5, 10.11.6 Security Update 2017-002 El Capitan, 10.10.5 Security Update 2017-002 Yosemite
  • Safari Versions prior to 10.1.1
  • iCloud for Windows Versions prior to 6.2.1
  • iTunes for Windows versions prior to 12.6.1

Risk to Government: High / medium

Risk to Business: High / medium

Risk to Home Users: Low

For more information see advisory at https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-apple-products-could-allow-for-arbitrary-code-execution-11/

Preparing for the General Data Protection Regulation (GDPR)

12 steps to take now towards GDPR compliance

The General Data Protection Regulation (GDPR) was on track to come into force in the UK on 25 May 2018 but the result of the June 2016 referendum on membership of the EU now means that the Government needs to consider the impact on the GDPR.

When implemented in the EU, the GDPR will be relevant for many organisations in the UK especially those operating internationally. The GDPR has several new features – such as breach notification and data portability.

With so many businesses and services operating across borders, international consistency around data protection laws and rights is crucial both to businesses and organisations and to consumers and citizens.

1. Awareness

You should make sure that decision makers and key people in your organisation are aware that the law is changing to the GDPR. They need to appreciate the impact this is likely to have and find areas that could cause compliance problems under the GDPR. It would be useful to start by looking at your organisation’s risk register, if you have one.

Implementing the GDPR could have significant resource implications, especially for larger and more complex organisations. You should particularly use the first part of the GDPR’s two-year lead-in period to raise awareness of the changes that are coming. You may find compliance difficult if you leave your preparations until the last minute.

2. Information you hold

You should document what personal data you hold, where it came from and who you share it with. You may need to organise an information audit, across the organisation, or within particular business areas.

The GDPR updates rights for a networked world. For example, if you have inaccurate personal data and have shared this with another organisation, you will have to tell the other organisation about the inaccuracy so it can correct its own records. You won’t be able to do this unless you know what personal data you hold, where it came from and who you share it with. You should document this. Doing this will also help you to follow the GDPR’s accountability principle, which requires organisations to be able to show how they comply with the data protection principles, such as by having effective policies and rules in place.

3. Communicating privacy information

You should check your current privacy notices and put a plan in place for making any necessary changes in time for GDPR implementation. When you collect personal data you now have to give people certain information, such as your identity and how you intend to use their information. This is usually done through a privacy notice. Under the GDPR there are some extra things you will have to tell people. For example, you will need to explain your legal basis for processing the data, your data retention periods and that people have a right to complain to the Information Commissioner’s Office if they think there is a problem with the way you are handling their data. Note that the GDPR requires the information to be provided in concise, easy to understand and clear language.

4. Individuals’ rights

You should check your procedures to make sure they cover all the rights people have, including how you would delete personal data or give data electronically and in a commonly used format.

The main rights for people under the GDPR will be:

  • subject access,
  • to have inaccuracies corrected,
  • to have information erased,
  • to prevent direct marketing,
  • to prevent automated decision-making and profiling, and
  • data portability.

The rights people will enjoy under the GDPR are the same as those under the DPA but with some significant enhancements. If you are geared up to give people their rights now, then the transition to the GDPR should be relatively easy. This is a good time to check your procedures and to work out how you would react if someone asks to have their personal data deleted, such as – Would your systems help you to find and delete the data? Who will make the decisions about deletion?

The right to data portability is new. This is an enhanced form of subject access where you have to give the data electronically and in a commonly used format. Many organisations will already offer the data in this way, but if you use paper print-outs or an unusual electronic format, now is a good time to revise your procedures and make any necessary changes.

5. Subject access requests

You should update your procedures and plan how you will handle requests within the new timescales and give any more information.

The rules for dealing with subject access requests will change under the GDPR. In most cases you will not be able to charge for complying with a request and normally you will have just a month to comply, rather than the current 40 days. There will be different grounds for refusing to comply with subject access request – manifestly unfounded or excessive requests can be charged for or refused. If you want to refuse a request, you will need to have policies and procedures in place to demonstrate why the request meets these criteria.

You will also need to provide some additional information to people making requests, such as your data retention periods and the right to have inaccurate data corrected. If your organisation handles a large number of access requests, the impact of the changes could be considerable so the logistical implications of having to deal with requests more quickly and provide additional information will need thinking through carefully. It could ultimately save your organisation a great deal of administrative cost if you can develop systems that allow people to access their information easily online. Organisations should consider conducting a cost/benefit analysis of providing online access.

6. Legal basis for processing personal data

You should look at the various types of data processing you carry out, identify your legal basis for carrying it out and document it.

Many organisations will not have thought about their legal basis for processing personal data. Under the current law this does not have many practical implications. However, this will be different under the GDPR because some individuals’ rights will be modified depending on your legal basis for processing their personal data. The most obvious example is that people will have a stronger right to have their data deleted where you use consent as your legal basis for processing.

You will also have to explain your legal basis for processing personal data in your privacy notice and when you answer a subject access request. The
legal bases in the GDPR are broadly the same as those in the DPA so it should be possible to look at the various types of data processing you carry out and to identify your legal basis for doing so. Again, you should document this in order to help you comply with the GDPR’s ‘accountability’ requirements.

7. Consent

You should review how you are seeking, obtaining and recording consent and whether you need to make any changes.

Like the The Data Protection Act 1998 (DPA), the GDPR has references to both ‘consent’ and ‘explicit consent’. The difference between the two is not clear given that both forms of consent have to be freely given, specific, informed and unambiguous. Consent also has to be a positive indication of agreement to personal data being processed – it cannot be inferred from silence, pre-ticked boxes or inactivity. If you rely on individuals’ consent to process their data, make sure it will meet the standards required by the GDPR. If not, alter your consent mechanisms or find an alternative to consent.
Note that consent has to be verifiable and that individuals generally have stronger rights where you rely on consent to process their data.

The GDPR is clear that controllers must be able to demonstrate that consent was given. You should therefore review the systems you have for recording consent to ensure you have an effective audit trail.

8. Children

You should start thinking now about putting systems in place to verify individuals’ ages and to gather parental or guardian consent for the data
processing activity.

For the first time, the GDPR will bring in special protection for children’s personal data, particularly in the context of commercial internet services
such as social networking. In short, if your organisation collects information about children – in the UK this will probably be defined as anyone under 13 – then you will need a parent or guardian’s consent in order to process their personal data lawfully. This could have significant implications if your organisation aims services at children and collects their personal data. Remember that consent has to be verifiable and that when collecting children’s data your privacy notice must be written in language that children will understand.

9. Data breaches

You should make sure you have the right procedures in place to detect, report and investigate a personal data breach.

Some organisations are already required to notify the ICO (and possibly some other bodies) when they suffer a personal data breach. However, the GDPR will bring in a breach notification duty across the board. This will be new to many organisations. Not all breaches will have to be notified to the ICO – only ones where the individual is likely to suffer some form of damage, such as through identity theft or a confidentiality breach.

You should start now to make sure you have the right procedures in place to detect, report and investigate a personal data breach. This could involve assessing the types of data you hold and documenting which ones would fall within the notification requirement if there was a breach. In some cases you will have to notify the individuals whose data has been subject to the breach directly, for example where the breach might leave them open to financial loss. Larger organisations will need to develop policies and procedures for managing data breaches – whether at a central or local level. Note that a failure to report a breach when required to do so could result in a fine, as well as a fine for the breach itself.

10. Data Protection by Design and Data Protection Impact Assessments

Data Privacy Impact Assessments (DPIAs) are a tool which can help organisations identify the most effective way to comply with their data protection obligations and meet individuals’ expectations of privacy. An effective DPIA will allow organisations to identify and fix problems at an early stage, reducing the associated costs and damage to reputation which might otherwise occur. DPIAs are an integral part of taking a privacy by design approach.

DPIAs can link to other organisational processes such as risk management and project management. You should start to assess the situations where it
will be necessary to conduct a DPIA. Who will do it? Who else needs to be involved? Will the process be run centrally or locally?

It has always been good practice to adopt a privacy by design approach and to carry out a privacy impact assessment as part of this. A privacy by
design and data minimisation approach has always been an implicit requirement of the data protection principles. However, the GDPR will
make this an express legal requirement.

You do not always have to carry out a DPIA but it is required in high-risk situations, for example where a new technology is being deployed or where a profiling operation is likely to significantly affect individuals. Where a DPIA indicates high risk data processing, you will be required to consult the ICO to seek its opinion as to whether the processing operation complies with the GDPR.

11. Data Protection Officers

You should designate a Data Protection Officer, if required, or someone to take responsibility for data protection compliance and assess where this
role will sit within your organisation’s structure and governance arrangements.

The GDPR will require some organisations to designate a Data Protection Officer (DPO), for example public authorities or ones whose activities involve the regular and systematic monitoring of data subjects on a large scale. The important thing is to make sure that someone in your
organisation, or an external data protection advisor, takes proper responsibility for your data protection compliance and has the knowledge, support and authority to do so effectively. Therefore you should consider now whether you will be required to designate a DPO and, if so, to assess
whether your current approach to data protection compliance will meet the GDPR’s requirements.

12. International

If your organisation operates internationally, you should determine which data protection supervisory authority you come under.

The GDPR contains quite complex arrangements for working out which data protection supervisory authority takes the lead when investigating a complaint with an international aspect, for example where a data processing operation affects people in a number of Member States. Put simply, the lead authority is determined according to where your organisation has its main administration or where decisions about data processing are made. In a traditional headquarters (branches model), this is easy to determine. It is more difficult for complex, multi-site companies where decisions about different processing activities are taken in different places. In case of uncertainty over which supervisory authority is the lead for your organisation, it would be helpful for you to map out where your organisation makes its most significant decisions about data processing. This will help to determine your ‘main establishment’ and therefore your lead supervisory authority.

IOT Security

IoT Attack Surface Areas

IoT Attack Surface Areas
Attack Surface Vulnerability
Ecosystem (general)
  • Interoperability standards
  • Data governance
  • System wide failure
  • Individual stakeholder risks
Ecosystem Access Control
  • Implicit trust between components
  • Enrolment security
  • Decommissioning system
  • Lost access procedures
Device Memory
  • Cleartext usernames
  • Cleartext passwords
  • Third-party credentials
  • Encryption keys
Device Physical Interfaces
  • Firmware extraction
  • User CLI
  • Admin CLI
  • Privilege escalation
  • Reset to insecure state
  • Removal of storage media
  • Tamper resistance
  • Debug port
  • Device ID/Serial number exposure
Device Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
Device Firmware
  • Hardcoded credentials
  • Sensitive information disclosure
  • Sensitive URL disclosure
  • Encryption keys
  • Encryption (Symmetric, Asymmetric)
  • Firmware version display and/or last update date
  • Backdoor accounts
  • Vulnerable services (web, ssh, tftp, etc.)
  • Security related function API exposure
  • Firmware downgrade
Device Network Services
  • Information disclosure
  • User CLI
  • Administrative CLI
  • Injection
  • Denial of Service
  • Unencrypted Services
  • Poorly implemented encryption
  • Test/Development Services
  • Buffer Overflow
  • UPnP
  • Vulnerable UDP Services
  • DoS
  • Device Firmware OTA update block
  • Replay attack
  • Lack of payload verification
  • Lack of message integrity check
Administrative Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Security/encryption options
  • Logging options
  • Two-factor authentication
  • Inability to wipe device
Local Data Storage
  • Unencrypted data
  • Data encrypted with discovered keys
  • Lack of data integrity checks
  • Use of static same enc/dec key
Cloud Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Third-party Backend APIs
  • Unencrypted PII sent
  • Encrypted PII sent
  • Device information leaked
  • Location leaked
Update Mechanism
  • Update sent without encryption
  • Updates not signed
  • Update location writable
  • Update verification
  • Update authentication
  • Malicious update
  • Missing update mechanism
  • No manual update mechanism
Mobile Application
  • Implicitly trusted by device or cloud
  • Username enumeration
  • Account lockout
  • Known default credentials
  • Weak passwords
  • Insecure data storage
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Vendor Backend APIs
  • Inherent trust of cloud or mobile application
  • Weak authentication
  • Weak access controls
  • Injection attacks
  • Hidden services
Ecosystem Communication
  • Health checks
  • Heartbeats
  • Ecosystem commands
  • Deprovisioning
  • Pushing updates
Network Traffic
  • LAN
  • LAN to Internet
  • Short range
  • Non-standard
  • Wireless (WiFi, Z-wave, Zigbee, Bluetooth)
  • Protocol fuzzing
  • Authentication/Authorization related values (session key, token, cookie, etc.) disclosure
  • Reusing of session key, token, etc.
  • Device to device authentication
  • Device to mobile Application authentication
  • Device to cloud system authentication
  • Mobile application to cloud system authentication
  • Web application to cloud system authentication
  • Lack of dynamic authentication
  • User data disclosure
  • User/device location disclosure
  • Differential privacy
Hardware (Sensors)
  • Sensing Environment Manipulation
  • Tampering (Physically)
  • Damaging (Physically)

What’s DDoS?

App Security

How to 301 Redirect All Requests on Google App Engine

We need two files to set this up:

app.yaml is the configuration file for the app.
main.py is a redirect script.


application: your-app-name
version: 1
runtime: python27
api_version: 1
threadsafe: no

– url: /.*
script: main.app


import webapp2

class MainPage(webapp2.RequestHandler):
def get(self):
self.redirect(“https://yourwebsite.com”, permanent=True)

app = webapp2.WSGIApplication([
(‘/.*’, MainPage),
], debug=True)

SEO Security

SEO Security