Gather and scan public information:
First we’ll explore the site and gather information about it as an outside or public user. A page crawler will look for robots.txt or some other kind of sitemap as well as some manual exploration to
discover what is available to a public user. Different user agents will be used to see if the server responds differently to different devices and if some of the agents look like they weren’t prepared
correctly we’ll try to see what might be missing on them that would provide a vulnerability. During this exploration and information gathering phase we’ll document the technologies a public user can
identify running in the system including operating systems, hostnames, ports, and any third party hosted content as well as application entry points and compare existing vulnerabilities to those
technologies and entry methods. We’ll finally scan the public facing code for API keys or security credentials in hidden files.
Scan for authentication rules and procedures:
We’ll attempt to bypass authentication using different methods. We’ll use a password generator to attempt a brute force entry and test the password rules and failed login attempts and anti-automation
rules and lockouts. We’ll attempt to use autocomplete functions and “remember me” types of functionality as an outside user by scanning for hidden data related to those functions. We’ll test captchas
and dependent authentication procedures for methods to bypass other required login tasks. We’ll attempt to validate digital certificates using duration, common name and signatures. We’ll attempt to
steal credentials of other users using the password recovery methods. We’ll test for default logins or any type of login history that is accessible to the public user or any notifications about user
password or credential changes.
Scan for configuration and known technology vulnerabilities:
Once we know more about what is available to us we’ll scan for URLs within that information that should be reserved for administration and application functions only and see if we can operate them as a
public user. We’ll scan for backup files or non-production files that show to a public user in a live environment and see if they contain any non-public data. We’ll scan for HTTP methods supported and
see if we can use cross site tracing to hijack user sessions.
Scan user session management and privilege authorization:
First we’ll need to see if we can establish methods in use, tokens, URLS, cookies etc. We’ll review the session data within those files to find methods and ensure compliance. We’ll scan that data for
algorithmic issues with max lifetime, timeouts, logins and log outs, and simultaneous sessions. We’ll test for URLs and tokens to confirm they change securely on critical changes to the user’s state
including log in, log out and role changes. We’ll test to see if we can use emulated cookie and URL data to change user sessions or authorization roles for users. Well test vertical and horizontal
authorization for issues with privilege escalation or cross control problems.
We’ll use a packet sniffer tool to steal data in transmission using our previously discovered knowledge of ports, SSL, encryption keys, etc. Using any known or discovered SSL versions and key lengths to
attempt to generate or steal a key we’ll attempt to decrypt the data in transmission. We’ll confirm that required sensitive data areas only use HTTPS and/or HSTS including session tokens, login forms,
credentials and other protected data areas and that all encryption procedures are in effect. We’ll scan the cache to ensure the management on HTTP is functioning correctly in terms of properties like
expiration dates and maximum ages.
Attempt data validation and injection:
This is where most of and the most critical vulnerabilities will likely be found. First we’ll test for known cross site scripting and injection methods to see if we can fool the application into accepting
our code. Our injection tests will use HTML, SQL, LDAP, ORM, XML, XXE, SSI, XPath, XQuery, IMAP/SMTP, expression language, command line, and web Code (ASP or PHP) confirming each fails at sending bad data
for execution. We’ll test for Boolean, string, and other formats as credential values. We’ll test for heap overflow to uncover private data in memory segments. We’ll attempt HTTP verb tampering to ensure
the application only executes expected requests. We’ll use any data validation issues or possibly even functional features of the app to execute incubated testing to find if any data vulnerabilities in
conjunction will show an exploit. Using a variety of user agents we’ll attempt to smuggle or split HTTP requests to expose cross scripting vulnerabilities. We’ll try to create a phishing vulnerability by
scanning for open redirects. We’ll attempt to steal data, deny service or cause exceptions using file inclusion vulnerabilities to add a remote or local file.
Test for misuse of implemented features by skipping steps, and attempting unexpected inputs and configurations. Test the integrity of trust relationships between features. Examine data integrity and test
for separation of duties between functions so that the same entity can’t create, authorize, and carry out an action.
DoS and DDoS:
Denial of service can come in many forms, multiple forms can be stopped on a developer level, in this section we’ll test for HTTP protocol and SQL wildcard DoS. Results from injection data and account
lockout may lead to an attempt at distributed denial of service attempt on the host.
We’ll test how the file uploads handle unexpected extensions to ensure they are protected against accepting malicious files. We’ll also try to execute malicious files on the server if they are accepted.
Ensure all unsafe filenames and types are sanitized. Attempt to find uploaded files in the web roots and possibly operate them. Test to see if files are served on the same hostname and port. Ensure all
acceptable types of data are whitelisted. Test that file types match the defined value. Test that size limitations, file counts, anti-virus scanning, and upload frequency rules are functioning as intended.
Ensure data that should not be encrypted is not being encrypted. Check for password salting and ensure the implementation methodologies are best practices including length requirements and avoiding the
same salts in multiple hashes. Report encryption key lengths and known key information.
HTML 5 has a few known threats that if not handled correctly can show a vulnerability. We’ll perform a web messaging test, web storage SQL injection, CORS implementation and offline web application state
test for defects.
Card Payment Processing:
We’ll test for all known vulnerabilities with a Common Vulnerability Scoring System (CVSS) score of greater than 4, scanning both for application and server configuration issues. We’ll search for issues
with buffer overflows, insecure storage, transport layer protection, and proper error handling. Finally we’ll attempt a cross-site request forgery to double check referrer headers and cookies to see if
we can create a session riding issue.
Many times finding vulnerabilities will not lead to an exploit or critical exploit by themselves, so in the final testing phase we’ll use our knowledge of any discovered vulnerabilities and, if possible,
combine them to work in tandem to try and cause a different or more critical vulnerability. After that final step is complete we’ll submit a full report on our analysis issuing warnings for any
vulnerabilities or risks and details of any full exploits found and then assign the application an overall pass/fail indicator.
Contact Code Authority online anytime or call our Dallas based office at 469-656-5036 for testing services.