Application Security Assessment

Fresh Perspective on Security

Online banking, online healthcare, online insurance, online document sharing…you get the picture. Whether you’re in the business of developing applications or you’ve contracted custom development, your applications could make or break your company. Not to mention, it’s easy to be “too close to the project” or to just assume that your developer built your application with security in mind. Let our AssureIT team put a fresh set of eyes on your application, ensuring it’s security and performance for years to come. Wondering if we have you covered? Our work includes:

  • OWASP Top 10 based web application assessments
  • OWASP Top 10 based mobile application assessments
  • Web service and API assessments
  • eCommerce application assessments for PCI requirements
  • Denial of service and stress testing
  • Windows client-server application assessments

From health insurance portals to online banking applications, the unique nature of a developer’s work does not stop at software engineering. But, focusing on DevOps, support, and versioning should be your work, and ours should be ensuring the security and reliability of your next rollout.

Partner with AssureIT in your next development.

Applications Are Designed to Enable, Make Sure That Yours Do

Application Testing Benefits From AssureIT

Industry-Specific Experience

As a comprehensive provider of information assurance consulting services, SynerComm helps clients in nearly all industries. Whether you are protecting credit card data (PCI), protected health information (PHI), or personally identifiable information (PII), you can trust our track record of securing critical applications.

Not So Automated Approach

Our application assessments go beyond automated testing and delve deep into application logic and security controls, giving you peace of mind and not just a compliance checkmark. Just like tools in the hands of a surgeon, they are only as good as the person using them.

Blind or Privileged Approaches

Depending on your goals, we can focus on the public portions of an application including authentication, encryption, provisioning, and session management, or deeply assess your systems as an authenticated user to mimic a scenario where an attacker has obtained authenticated access to an application or web service.

OWASP Top 10 - Web & Mobile

Someone really smart must have said, “why reinvent the wheel?” because we couldn’t agree more. SynerComm closely follows and utilizes the OWASP Top 10 projects as we perform web and mobile application assessments.
Web Apps - OWASP Top 10 Vulnerabilities

A1 - Injection

Injection flaws, such as SQL, 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 - Broken Authentication

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

A3 - 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 may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

A4 - XML External Entities (XXE)

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 - Broken Access Control

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 - Security Misconfiguration

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 and upgraded in a timely fashion.

A7 - 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 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 - Insecure Deserialization

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 - Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

A10 - Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Mobile Apps - OWASP Top 10 Vulnerabilities

M1 - Improper Platform Usage

This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

M2 - Insecure Data Storage

This new category is a combination of M2 + M4 from Mobile Top Ten 2014. This covers insecure data storage and unintended data leakage.

M3 - Insecure Communication

This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

M4 - Insecure Authentication

This category captures notions of authenticating the end user or bad session management. This can include:

  • Failing to identify the user at all when that should be required
  • Failure to maintain the user’s identity when it is required
  • Weaknesses in session management

M5 - Insufficient Cryptography

The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn’t done correctly.

M6 - Insecure Authorization

This is a category to capture any failures in authorization (e.g., authorization decisions on the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrollment, user identification, etc.).

If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure, not an authorization failure.

M7 - Client Code Quality

This was the “Security Decisions Via Untrusted Inputs”, one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That’s distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

M8 - Code Tempering

This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

M9 - Reverse Engineering

This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back-end servers, cryptographic constants and ciphers, and intellectual property.

M10 - Extraneous Functionality

Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.

Contact Us today for more information.