It is compatible with OWASPTOP10, IPA's How to Secure Your Web Site and ASVS4.0. The main peak values to be scanned are listed below.
*The actual scan rules included in each scan rule set can be checked from the Custom Scan Ruleset function.
Web Application Scan
The following items are included in the scan ruleset "Web Application Scan".
■OWASPTOP10
A1:2017-Injection
・Description
Injection flaws, such as SQL, NoSQL, OS, 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 authorization.
A2:2017-Broken Authentication
・Description
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:2017-Sensitive Data Exposure
・Description
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 may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
A4:2017-XML External Entities (XXE)
・Description
Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
A5:2017-Broken Access Control
・Description
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
A6:2017-Security Misconfiguration
・Description
Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
A7:2017-Cross-Site Scripting (XSS)
・Description
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 HTML or 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.
A8:2017-Insecure Deserialization
・Description
Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
A9:2017-Using Components with Known Vulnerabilities
・Description
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 defenses and enable various attacks and impacts.
Other:Other
・Description
Vulnerabilities not categorized in OWASP TOP 10.
■OWASP ASVS4.0 Level 1
2.1.1
Verify that user set passwords are at least 12 characters in length. (C6)
2.1.2
Verify that passwords 64 characters or longer are permitted. (C6)
2.1.3
Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced. (C6)
2.1.4
Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
2.1.6
Verify that password change functionality requires the user's current and new password.
2.1.7
Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new nonbreached password. (C6)
2.1.9
Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. (C6)
2.1.11
Verify that "paste" functionality, browser password helpers, and external password managers are permitted.
2.2.1
Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.
2.5.2
Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.
2.5.3
Verify password credential recovery does not reveal the current password in any way. (C6)
2.5.4
Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
3.1.1
Verify the application never reveals session tokens in URL parameters or error messages.
3.2.1
Verify the application generates a new session token on user authentication. (C6)
3.2.2
Verify that session tokens possess at least 64 bits of entropy. (C6)
3.2.3
Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.
3.3.1
Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. (C6)
3.4.1
Verify that cookie-based session tokens have the 'Secure' attribute set. (C6)
3.4.2
Verify that cookie-based session tokens have the 'HttpOnly' attribute set. (C6)
3.4.3
Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. (C6)
3.4.4
Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality.
3.7.1
Verify the application ensures a valid login session or requires reauthentication or secondary verification before allowing any sensitive transactions or account modifications.
4.1.1
Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
4.1.2
Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
4.1.3
Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. (C7)
4.1.4
Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. (C7)
4.1.5
Verify that access controls fail securely including when an exception occurs. (C10)
4.2.1
Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.
4.2.2
Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.
4.3.2
Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
5.1.2
Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. (C5)
5.1.3
Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting). (C5)
5.1.4
Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). (C5)
5.1.5
Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content.
5.2.1
Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. (C5)
5.2.2
Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.
5.2.3
Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
5.2.4
Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.
5.2.5
Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.
5.2.6
Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, use whitelisting of protocols, domains, paths and ports.
5.2.7
Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.
5.2.8
Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.
5.3.1
Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). (C4)
5.3.2
Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. (C4)
5.3.3
Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. (C4)
5.3.4
Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. (C3)
5.3.5
Verify that where parameterized or safer mechanisms are not present, contextspecific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. (C3, C4)
5.3.6
Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation. (C4)
5.3.7
Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented. (C4)
5.3.8
Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. (C4)
5.3.9
Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
5.3.10
Verify that the application protects against XPath injection or XML injection attacks. (C4)
5.5.1
Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. (C5)
5.5.2
Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XXE.
5.5.3
Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).
5.5.4
Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.
6.2.1
Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
8.2.1
Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.
8.2.2
Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII.
8.2.3
Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.
8.3.1
Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.
9.1.1
Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. (C8)
9.1.2
Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.
9.1.3
Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.
10.3.2
Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.
10.3.3
Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.
11.1.1
Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.
11.1.2
Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.
11.1.3
Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.
11.1.5
Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modelling or similar methodologies.
12.3.1
Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path traversal.
12.3.2
Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).
12.3.3
Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI), which may also lead to SSRF.
12.3.4
Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.
12.3.5
Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.
12.4.1
Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.
12.4.2
Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.
12.5.1
Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.
12.5.2
Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.
12.6.1
Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or load data/files from.
13.1.1
Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.
13.1.2
Verify that access to administration and management functions is limited to authorized administrators.
13.1.3
Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
13.2.1
Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.
13.2.2
Verify that JSON schema validation is in place and verified before accepting input.
13.2.3
Verify that RESTful web services that utilize cookies are protected from CrossSite Request Forgery via the use of at least one or more of the following: triple or double submit cookie pattern (see references), CSRF nonces, or ORIGIN request header checks.
13.3.1
Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.
14.2.1
Verify that all components are up to date, preferably using a dependency checker during build or compile time. (C2)
14.2.2
Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.
14.2.3
Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.
14.3.1
Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.
14.3.2
Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.
14.3.3
Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
14.4.1
Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).
14.4.2
Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type).
14.4.3
Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.
14.4.4
Verify that all responses contain X-Content-Type-Options: nosniff.
14.4.5
Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.
14.4.6
Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin".
14.4.7
Verify that a suitable X-Frame-Options or Content-Security-Policy: frameancestors header is in use for sites where content should not be embedded in a third-party site.
14.5.1
Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.
14.5.2
Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker
14.5.3
Verify that the cross-domain resource sharing (CORS) Access-Control-AllowOrigin header uses a strict white-list of trusted domains to match against and does not support the "null" origin.
■Network Scan
・Port Scanning
TCP（0-65535）/ UDP（major ports) port status survey
・Banner Grabbing
Software Detection, Version Detection
・Service Detection
Service Configuration Flaws Inspection e.g. Telnet,FTP,SMTP,etc.
・Account Inspection
Default Account Detection Authentication Lack Inspection
■SSL/TLS Encryption Strength Inspection Cryptographic Algorithm Compromise Inspection *Final confirmation date: October 28, 2024
We are investigating the use of the ciphers recommended by NIST Special Publication 800-52 Revision 2 and Mozilla Security/Server Side TLS.
In addition, TLS cipher suites is referenced in Internet Assigned Numbers Authority.
■OWASP API Security Top10 2023
The following is a list of items that can only be detected by the 'API scan function'.
*The API Scan function is an optional feature that can only be added to the Business plan.
・API1:2023 Broken Object Level Authorization
・API2:2023 Broken Authentication
・API3:2023 Broken Object Property Level Authorization
・API5:2023 Broken Function Level Authorization
・API7:2023 Server Side Request Forgery
・API8:2023 Security Misconfiguration
・API9:2023 Improper Inventory Management
*For an overview of each item, see here.