FAQ

If ASoC detects that the automated process may produce less than optimal results, scan status changes to "Scan under review". The settings will be reviewed by our team of Scan Enablers, and may be modified to ensure the best scan results. No input is needed from you at this stage, and you should not cancel the scan as this will cancel the review. As soon as the settings have been reviewed (usually within a few hours), the scan will resume and complete.

Possible reasons your scan might fail or come under review include:

Invalid login credentials
Login requires a third or other unusual login procedure
Login uses CAPTCHA (CAPTCHA is not supported; if your login uses CAPTCHA you must disable it for the scan)
Invalid app file
Invalid or missing HTTP Authentication credentials
Server not responding or bad gateway (ASoC sends many requests, so the site/app must be stable, and able to cope with heavy traffic)
IP blocked (make sure to whitelist the IPs used by ASoC)
Account lockout
Results require manual verification
The Test Policy (set of tests sent during the scan) that you selected is not suited to your site/app
Private Site Scans: AppScan Presence not active

Obviously if you are able to avoid these issues your scan is more likely to complete automatically and fast. This is especially important if you are incorporating ASoC scanning into an automated process, so scan time will be as short as possible.

What happens if the scan fails?

Your account is not charged.
If there is a diagnosis for why the scan failed, the system notifies you so you can fix it.

Can I delete my scan and still take advantage of the free rescan period?

No. If you click the Trash icon, the rescan option is voided and you must purchase a new scan.

Can I retrieve the scan results for a scan I deleted?

No. When you click the Trash icon the results are deleted from the database.

Can I retrieve the scan results for a previous scan after I rescanned?

No. When you rescan an application, the previous results are deleted from the database.

How long does a scan take to complete?

Depending on application size and complexity, from a few minutes to a few days. You can elect to receive an email when the scan is complete.

My scan seems to be taking a long time. Could it be stuck?

The monitoring system checks scan progress to ensure that scans that are not progressing are stopped. If the scan still appears to be running, it probably is.

How long do you keep my scans in your database if I don’t delete them?

Files uploaded by the user (such as APK, IPA, IRX, SCAN and SCANT) are cached in the service for no more then one month, for the purpose of troubleshooting. Scan results are permanently stored in the service unless the user deletes them, or the user account is deleted.

Which IPs does ASoC use?

See System Requirements

What security issues are Android mobile apps tested for?

Activity Hijacking
Android Class Loading Hijacking
Android Fragment Injection
Broadcast Theft
Buffer Overflow
Client-side SQL Injection
Constant Initialization Vector (IV)
Constant Password
Constant Salt
Constant Secret Key
Constant Seed
Constant Token
Crash in Java™ Code
Crash in Native Code
Credential Leakage
Cross-Application Scripting
Cross-Site Scripting (XSS) via Man-in-the-Middle (MiTM)
Debug Flag Enabled on Release Version
Debug Version Detected
Deprecated SSL Version is Supported
File Manipulation
Information leakage
Insecure File Permission
Insecure Pending Intent
Insecure Serialization
Insecure Serialization by Framework
Insecure TLS/SSL Trust Manager
Insecure WebView TLS/SSL Error Handler
Lack of Certificate Pinning
Phishing via Man-in-the-Middle (MiTM)
Service Hijacking
UI Spoofing
Unsafe Reflection
Weak Random Number Generator

What security issues are iOS mobile apps tested for?

AFNetworking Framework Vulnerability
Client Certificate Import
Credential Leakage
Credentials Stored Permanently
Cross-Site Scripting (XSS) via Man-in-the-Middle (MiTM)
Debug Symbols Presence
HTTP Request Hijacking
HTTPS Caching
HTTPS to HTTP redirection
Information Leakage
Insecurely Backgrounding Application
Keychain Data Protection
Lack of Certificate Pinning
Lack of Credential Validation
Malware - XCodeGhost
Man-in-the-Middle (MiTM)
Missing Domain-Name Validation
NSURL Credential Stored Permanently
Null Initialization Vector
Unsecured Pasteboard Usage
Phishing via Man-in-the-Middle (MiTM)
PIE Protection
Privacy Resources Access
The application in your IPA is unstripped Binary
Transport Security - Certificate Chain Validation
Weak SSL Cipher Suites are Supported
Weak JailBreak Detection
Weak Random Number Generator
XML External Entity (XXE) Processing

What is the difference between the Staging and Production scans for websites?

The Production scan is designed to have a reduced risk of affecting site stability, when the scan explores the site, forms are not submitted and a lower request rate is used.

What security issues are web apps tested for?

Abuse of Functionality
Brute Force
Buffer Overflow
Content Spoofing
Credential/Session Prediction
Cross-site Request Forgery
Cross-site Scripting
Denial of Service
Directory Indexing
Format String
HTTP Response Splitting
Information Leakage
Insecure Indexing
Insufficient Authentication
Insufficient Authorization
Insufficient Session Expiration
Insufficient Transport Layer Protection
Integer Overflows
LDAP Injection
Mail Command Injection
Malicious Content Tests
Null Byte Injection
OS Commanding
Path Traversal
Predictable Resource Location
Remote File Inclusion
Server Misconfiguration
Session Fixation
SOAP Array Abuse
SQL Injection
SSI Injection
URL Redirector Abuse
XML Attribute Blowup
XML Entity Expansion
XML External Entities
XML Injection
XPath Injection

Note: Although the same issues are tested for on staging and production sites, for some issues the production testing is not as thorough as the staging testing.

What security issues are web apps tested for with static testing?

AppDOS
Browser Caching Sensitive Information
Comments Reveal Sensitive Information
Configuration Issue
CrossSiteScripting (XSS)
DB Connection String Manipulation
Email Phishing
EMail Tampering
Encoding Required
Exposed Web Service
File Tampering
File Upload
HTTP Request Splitting
HTTPResponse Splitting
LDAP Injection
Open Redirect
OS Command Injection
Path Traversal Potential Business Logic Issue (also covers Insecure Direct Object Reference)
Privilege Escalation
RegEx Injection
Remove Test Code
SecondOrder Injection
Sensitive Data Exposure
Sensitive Data Stored in Logs
Sensitive Information Revealed in Error Message
Session Management Timeout Value Too Large
SQL Injection
Unencrypted Communications
URL Tampering
Use of Cryptographically Unsafe Random Number Generator
Use of Hidden Fields
Use of Insecure Cryptography Algorithm
Use of Unsafe Native Code
Weak Access Control
Weak Authentication
XML Injection
XPath Injection
XSLT Injection

What is a static analysis IRX file and what does it contain?

IRX is a secure and encrypted zip archive that contains the information that is necessary to run a full static analysis of your program. It is encrypted at-rest upon creation, as well as during transport to the cloud (over SSL).

Internally, an IRX archive contains these files and artifacts:

An IBM-designed proprietary and obfuscated representation of your deployable program artifacts, built from your deployed source code (for example, Java bytecode or .Net MSIL). To learn which languages are supported for static analysis scans, see System requirements for static analysis).
Any runtime script files that are deployed with your program that can be analyzed for security vulnerabilities (for example .js (Javascript) or .rb (Ruby) files).
Static Analyzer configuration files that describe the application or project hierarchy and relationships or dependencies of your program. This allows for accurate and complete security analysis across project boundaries within your application.
Static Analyzer log files generated during the creation of the archive (for diagnostics and support).