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.
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?

SEO Security

SEO Security