nosu
/
security-c4po
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
security-c4po/security-c4po-angular/src/assets/i18n/en-US.json

564 lines
137 KiB
JSON
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

{
"global": {
"actions": "Actions",
"action.profile": "Profile",
"action.login": "Login",
"action.logout": "Logout",
"action.retry": "Try again",
"action.info": "Info",
"action.confirm": "Confirm",
"action.save": "Save",
"action.cancel": "Cancel",
"action.return": "Return",
"action.exit": "Exit",
"action.update": "Update",
"action.edit": "Edit",
"action.export": "Export",
"action.download": "Download",
"action.report": "Report",
"action.reset": "Reset",
"action.complete": "Complete",
"action.disable": "Deactivate",
"action.enable": "Activate",
"action.yes": "Yes",
"action.no": "No",
"username": "Username",
"password": "Password",
"no.progress": "No progress",
"project": "Project",
"version": "Version",
"validationMessage": {
"inputNotMatching": "Input does not match!"
},
"retry.dialog": {
"title": "Something went wrong...",
"information": "An error occured while processing your request. \nPlease retry or try it again later."
}
},
"languageKeys":{
"de-DE": "German",
"en-US": "English"
},
"popup": {
"success": "✔",
"failure": "✘",
"warning": "!",
"info": "ⓘ",
"error.position": {
"permissionDenied": "Permission denied",
"timeout": "Timeout"
},
"login": {
"successful": "Login successful"
}
},
"login": {
"title": "Login",
"failed": "Wrong username or password",
"unauthorized": "User not found. Please register and try again"
},
"profile": {
"header": "Userprofile",
"username": {
"title": "Username",
"placeholder": "Username"
},
"firstName": {
"title": "Firstname",
"placeholder": "Firstname"
},
"lastName": {
"title": "Lastname",
"placeholder": "Lastname"
},
"validationMessage": {
"firstNameRequired": "Firstname is required.",
"lastNameRequired": "Lastname is required."
},
"languageLabel": "Change language:",
"password": {
"title": "Change password:",
"old": "Old password",
"new": "New password",
"confirmNew": "Confirm new password",
"validationMessage": {
"passwordRequired": "Password is required."
}
}
},
"state": {
"new": "New",
"needs_more_info": "Needs More Info",
"pre_submission": "Pre-submission",
"pending": "Pending",
"triaged": "Triaged",
"retesting": "Retesting",
"resolved": "Resolved",
"informative": "Informative",
"duplicate": "Duplicate",
"not_applicable": "Not Applicable",
"spam": "Spam",
"out_of_scope": "Out Of Scope",
"accepted_risk": "Accepted Risk"
},
"report": {
"dialog": {
"header": "Export Penetrationtest Report",
"formatLabel": "Pick export format for report:",
"languageLabel": "Pick report language:"
},
"popup": {
"generation.success": "Report generation successful",
"generation.failed": "Report could not be generated"
},
"generate": "Generate Report",
"hint": "{{completedObjectivesNumber}} of your completed objective(s) will be included in the pentest report."
},
"project": {
"title.label": "Project Title",
"client.label": "Name of Client",
"tester.label": "Name of Pentester",
"state.label": "State of Pentest",
"summary.label": "Summary",
"summary.placeholder": "Should include Executive Summary, Approach, Scope and Assessment Overview as well as General Recommendations",
"title": "Title",
"client": "Client",
"tester": "Tester",
"state": "State of Pentest",
"summary": "Summary",
"createdAt": "Created at",
"overview": {
"add.project": "Add Project",
"no.projects": "No projects available"
},
"filter": {
"placeholder": "Search through all {{allProjectsCount}} project(s).."
},
"create": {
"header": "Create New Project"
},
"edit": {
"header": "Edit Project"
},
"delete": {
"title": "Delete Project",
"key": "Do you want to permanently delete the project \"{{name}}\"?",
"confirmStringPlaceholder": "Enter project title to confirm",
"sec.key": "Do you want to permanently delete the project \"{{name}}\"? \nAll related data will also be deleted."
},
"validationMessage": {
"titleRequired": "Title is required.",
"clientRequired": "Client is required.",
"testerRequired": "Tester is required.",
"stateRequired": "State is required.",
"summaryRequired": "Summary is required."
},
"popup": {
"not.found": "No projects found",
"save.success": "Project saved successfully",
"save.failed": "Project could not be saved",
"update.success": "Project updated successfully",
"update.failed": "Project could not be updated",
"delete.success": "Project deleted successfully",
"delete.failed": "Project could not be deleted"
}
},
"categories": {
"INFORMATION_GATHERING": "Information Gathering",
"CONFIGURATION_AND_DEPLOY_MANAGEMENT_TESTING": "Config & Deploy Management Testing",
"IDENTITY_MANAGEMENT_TESTING": "Identity Management Testing",
"AUTHENTICATION_TESTING": "Authentication Testing",
"AUTHORIZATION_TESTING": "Authorization Testing",
"SESSION_MANAGEMENT_TESTING": "Session Management Testing",
"INPUT_VALIDATION_TESTING": "Input Validation Testing",
"ERROR_HANDLING": "Error Handling",
"CRYPTOGRAPHY": "Cryptography",
"BUSINESS_LOGIC_TESTING": "Business Logic Testing",
"CLIENT_SIDE_TESTING": "Client Side Testing"
},
"finding": {
"findingId": "Finding Id",
"severity": "Severity",
"title": "Title",
"description": "Description",
"impact": "Impact",
"affectedUrls": "Affected URL's",
"reproduction": "Reproduction",
"mitigation": "Mitigation",
"add": "Add finding",
"add.url": "Add affected Url",
"affectedUrls.placeholder": "Enter affected URL here..",
"create": {
"header": "Create New Finding"
},
"edit": {
"header": "Edit Finding"
},
"delete": {
"title": "Delete Finding",
"key": "Do you want to permanently delete the finding \"{{name}}\"?"
},
"severity.label": "Severity of Finding",
"title.label": "Finding Title",
"description.label": "Description of Finding",
"impact.label": "Impacted Applicationparts",
"affectedUrls.label": "Affected URL's",
"reproduction.label": "Reproductionsteps",
"mitigation.label": "Suggest Mitigation",
"no.findings": "No findings available",
"validationMessage": {
"titleRequired": "Title is required.",
"severityRequired": "Severity is required.",
"descriptionRequired": "Description is required.",
"impactRequired": "Impact is required.",
"affectedUrlsRequired": "Affected Url's required.",
"reproductionRequired": "Reproductionstep(s) are required.",
"mitigationRequired": "Mitigation is required."
},
"popup": {
"not.found": "No finding found",
"save.success": "Finding saved successfully",
"save.failed": "Finding could not be saved",
"update.success": "Finding updated successfully",
"update.failed": "Finding could not be updated",
"delete.success": "Finding deleted successfully",
"delete.failed": "Finding could not be deleted",
"not.available": "Finding is not available anymore"
}
},
"severities": {
"low": "Low",
"medium": "Medium",
"high": "High",
"critical": "Critical"
},
"comment": {
"commentId": "Comment Id",
"title": "Title",
"description": "Description",
"relatedFindings": "Related Findings",
"add": "Add Comment",
"add.finding": "Add related finding",
"no.comments": "No comments available",
"no.relatedFindings": "Not related to any finding",
"relatedFindingsPlaceholder": "Select a related finding",
"noFindingsInObjectivePlaceholder": "Objective doesn't have any findings to relate to.",
"create": {
"header": "Create New Comment"
},
"edit": {
"header": "Edit Comment"
},
"delete": {
"title": "Delete Comment",
"key": "Do you want to permanently delete the comment \"{{name}}\"?"
},
"title.label": "Comment Title",
"description.label": "Description of Comment",
"relatedFindings.label": "Related Findings",
"validationMessage": {
"titleRequired": "Title is required.",
"descriptionRequired": "Description is required.",
"relatedFindings": "Related findings required."
},
"popup": {
"not.found": "No comment found",
"save.success": "Comment saved successfully",
"save.failed": "Comment could not be saved",
"update.success": "Comment updated successfully",
"update.failed": "Comment could not be updated",
"delete.success": "Comment deleted successfully",
"delete.failed": "Comment could not be deleted",
"not.available": "Comment is not available anymore"
}
},
"pentest": {
"testId": "No.",
"title": "Title",
"findings": "Findings",
"comments": "Comments",
"findings&comments": "Findings & Comments",
"status": "Status",
"statusText": {
"not_started": "Not Started",
"disabled": "Disabled",
"open": "Open",
"paused": "Paused",
"in_progress": "In progress",
"completed": "Completed"
},
"disable": {
"title": "Disable Objective",
"key": "Do you want to disable the objective \"{{name}}\"?"
},
"enable": {
"title": "Enable Objective",
"key": "Do you want to enable the objective \"{{name}}\"?"
},
"popup": {
"not.found": "No pentest found",
"initial.save.success": "Initial Pentest successfully setup",
"initial.save.failed": "Initial Pentest could not be setup",
"save.success": "Pentest saved successfully",
"save.failed": "Pentest could not be saved",
"complete.success": "Pentest completed successfully",
"complete.failed": "Pentest could not be completed",
"update.success": "Pentest updated successfully",
"update.failed": "Pentest could not be updated",
"delete.success": "Pentest deleted successfully",
"delete.failed": "Pentest could not be deleted",
"disable.success": "Objective disabled successfully",
"disable.failed": "Objective could not be disabled",
"enable.success": "Objective enabled successfully",
"enable.failed": "Objective could not be enabled"
},
"info": {
"001": "Conduct Search Engine Discovery and Reconnaissance for Information Leakage",
"002": "Fingerprint Web Server",
"003": "Review Webserver Metafiles for Information Leakage",
"004": "Enumerate Applications on Webserver",
"005": "Review Webpage Comments and Metadata for Information Leakage",
"006": "Identify application entry points",
"007": "Map execution paths through application",
"008": "Fingerprint Web Application Framework",
"009": "Fingerprint Web Application",
"010": "Map Application Architecture"
},
"config": {
"001": "Test Network/Infrastructure Configuration",
"002": "Test Application Platform Configuration",
"003": "Test File Extensions Handling for Sensitive Information",
"004": "Backup and Unreferenced Files for Sensitive Information",
"005": "Enumerate Infrastructure and Application Admin Interfaces",
"006": "Test HTTP Methods",
"007": "Test HTTP Strict Transport Security",
"008": "Test RIA cross domain policy"
},
"ident": {
"001": "Test Role Definitions",
"002": "Test User Registration Process",
"003": "Test Account Provisioning Process",
"004": "Testing for Account Enumeration and Guessable User Account",
"005": "Testing for Weak or unenforced username policy",
"006": "Test Permissions of Guest/Training Accounts",
"007": "Test Account Suspension/Resumption Process"
},
"authn": {
"001": "Testing for Credentials Transported over an Encrypted Channel",
"002": "Testing for default credentials",
"003": "Testing for Weak lock out mechanism",
"004": "Testing for bypassing authentication schema",
"005": "Test remember password functionality",
"006": "Testing for Browser cache weakness",
"007": "Testing for Weak password policy",
"008": "Testing for Weak security question/answer",
"009": "Testing for weak password change or reset functionalities",
"010": "Testing for Weaker authentication in alternative channel"
},
"authz": {
"001": "Testing Directory traversal/file include",
"002": "Testing for bypassing authorization schema",
"003": "Testing for Privilege Escalation",
"004": "Testing for Insecure Direct Object References"
},
"sess": {
"001": "Testing for Bypassing Session Management Schema",
"002": "Testing for Cookies attributes",
"003": "Testing for Session Fixation",
"004": "Testing for Exposed Session Variables",
"005": "Testing for Cross Site Request Forgery",
"006": "Testing for logout functionality",
"007": "Test Session Timeout",
"008": "Testing for Session puzzling"
},
"inpval": {
"001": "Testing for Reflected Cross Site Scripting",
"002": "Testing for Stored Cross Site Scripting",
"003": "Testing for HTTP Verb Tampering",
"004": "Testing for HTTP Parameter pollution",
"005": "Testing for SQL Injection",
"005_1": "Oracle Testing",
"005_2": "MySQL Testing",
"005_3": "SQL Server Testing",
"005_4": "Testing PostgreSQL",
"005_5": "MS Access Testing",
"005_6": "Testing for NoSQL Injection",
"006": "Testing for LDAP Injection",
"007": "Testing for ORM Injection",
"008": "Testing for XML Injection",
"009": "Testing for SSI Injection",
"010": "Testing for XPath Injection",
"011": "IMAP/SMTP Injection",
"012": "Testing for Code Injection",
"012_1": "Testing Local File Inclusion",
"012_2": "Testing Remote File Inclusion",
"013": "Testing for Command Injection",
"014": "Testing for Buffer overflow",
"014_1": "Testing for Heap overflow",
"014_2": "Testing for Stack overflow",
"014_3": "Testing for Format string",
"015": "Testing for incubated vulnerabilities",
"016": "Testing for HTTP Splitting/Smuggling"
},
"err": {
"001": "Analysis of Error Codes",
"002": "Analysis of Stack Traces"
},
"crypst": {
"001": "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection",
"002": "Testing for Padding Oracle",
"003": "Testing for Sensitive information sent via unencrypted channels"
},
"buslogic": {
"001": "Test Business Logic Data Validation",
"002": "Test Ability to Forge Requests",
"003": "Test Integrity Checks",
"004": "Test for Process Timing",
"005": "Test Number of Times a Function Can be Used Limits",
"006": "Testing for the Circumvention of Work Flows",
"007": "Test Defenses Against Application Mis-use",
"008": "Test Upload of Unexpected File Types",
"009": "Test Upload of Malicious Files"
},
"client": {
"001": "Testing for DOM based Cross Site Scripting",
"002": "Testing for JavaScript Execution",
"003": "Testing for HTML Injection",
"004": "Testing for Client Side URL Redirect",
"005": "Testing for CSS Injection",
"006": "Testing for Client Side Resource Manipulation",
"007": "Test Cross Origin Resource Sharing",
"008": "Testing for Cross Site Flashing",
"009": "Testing for Clickjacking",
"010": "Testing WebSockets",
"011": "Test Web Messaging",
"012": "Test Local Storage"
}
},
"objectives": {
"info": {
"001": "The objective is to understand what sensitive design and configuration information of the application/system/organization is exposed both directly (on the organization’s website) or indirectly (on a third party website).\n\n There are direct and indirect elements to search engine discovery and reconnaissance. \n Direct methods relate to searching the indexes and the associated content from caches.\n Indirect methods relate to gleaning sensitive design and configuration information by searching forums, newsgroups, and tendering websites.\n\n Use a search engine to search for:\n• Network diagrams and configurations\n• Archived posts and emails by administrators and other key staff\n• Log on procedures and username formats\n• Usernames and passwords\n• Error message content\n• Development, test, UAT and staging versions of the website",
"002": "The objective is to find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits to use during testing.\n\n Web server fingerprinting is a critical task for the penetration tester.\nKnowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.\n\n There are several different vendors and versions of web servers on the market today. Knowing the type of web server that is being tested significantly helps in the testing process and can also change the course of the test. The simplest and most basic form of identifying a web server is to look at the Server field in the HTTP response header.\n\n By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures.",
"003": "The objective here is to check the robots.txt file for information leakage of the web application’s directory or folder path(s).\n\n 1. Information leakage of the web application’s directory or folder path(s). \n 2. Create the list of directories that are to be avoided by Spiders, Robots, or Crawlers. \n\n Furthermore, the list of directories that are to be avoided by Spiders, Robots, or Crawlers can also be created as a dependency for Map execution paths through application.\n Web Spiders, Robots, or Crawlers retrieve a web page and then recursively traverse hyperlinks to retrieve further web content. Their accepted behavior is specified by the Robots Exclusion Protocol of the robots.txt file in the web root directory.",
"004": "The objective is enumerate the applications within scope that exist on a web server.\n\n Many applications have known vulnerabilities and known attack strategies that can be exploited in order to gain remote control or to exploit data. In addition, many applications are often misconfigured or not updated. \n Web application discovery is a process aimed at identifying web applications on a given infrastructure. The latter is usually specified as a set of IP addresses (maybe a net block), but may consist of a set of DNS symbolic names or a mix of the two.",
"005": "The objective is to review webpage comments and metadata to better understand the application and to find any information leakage.\n\n HTML comments are often used by the developers to include debugging information about the application. Sometimes they forget aboutthe comments and they leave them on in production.\n\n Check HTML source code for comments containing sensitive information that can help the attacker gain more insight about the application. It might be SQL code, usernames and passwords, internal IP addresses, or debugging information.",
"006": "The objective is to understand how requests are formed and typical responses from the application.\n\n Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This aims to help identify and map out areas within the application that should be investigated once enumeration and mapping have been completed.\n\n While walking through the application, pay special attention to all HTTP requests (GET and POST Methods, also known as Verbs), as well as every parameter and form field that is passed to the application.\n In addition, take note of any interesting parameters in the URL, custom headers, or body of the requests/responses, and save them. \n Once every area of the application is mapped out, go through the application and test each of the areas that have been identified and make notes for what worked and what didn’t work.",
"007": "The objective is to Map the target application and understand the principal workflows.\n\n Before commencing security testing, understanding the structure of the application is paramount.\nThere are several ways to approach the testing and measurement of code coverage:\n\n 1. Path:\n Test each of the paths through an application that includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch.\n\n 2. Data flow (or taint analysis): \n Tests the assignment of variables via external interaction (normally users).\n Focuses on mapping the flow, transformation and use of data throughout an application.\n\n 3. Race:\n Tests multiple concurrent instances of the application manipulating the same data.",
"008": "The objective is to define type of used web framework so as to have a better understanding of the security testing methodology. \n\n Knowing the type of framework can automatically give a great advantage if such a framework has already been tested by the penetration tester. It is not only the known vulnerabilities in unpatched versions but specific misconfigurations in the framework and known file structure that makes the fingerprinting process so important.\n\n There are several most common locations to look in in order to define the current framework:\n• HTTP headers\n• Cookies\n• HTML source code\n• Specific files and folders",
"009": "The objective is to identify the web application and version to determine known vulnerabilities and the appropriate exploits to use during testing.\n\n With the vast number of free and open source software projects that are actively developed and deployed around the world, it is very likely that an application security test will face a target site that is entirely or partly dependent on these well known applications (e.g. Wordpress, phpBB, Mediawiki, etc).\n\nKnowing the web application components that are being tested significantly helps in the testing process.\nThese well known web applications have known HTML headers, cookies, and directory structures that can be enumerated to identify the application.",
"010": "The application architecture needs to be mapped through some test to determine what different components are used to build the web application.\n\n In small setups, such as a simple CGI-based application, a single server might be used that runs the web server which executes the C, Perl, or Shell CGIs application, and perhaps also the authentication mechanism.\n On more complex setups multiple servers might be involved. These may include a reverse proxy, a frontend web server, an application server and a database server or LDAP server. \nEach of these servers will be used for different purposes and might be even be divided in different networks with firewalls between them (DMZs). \n\n In addition, understanding the deployed configuration of the server hosting the web application is almost as important as the application security testing itself."
},
"config": {
"001": "The intrinsic complexity of interconnected and heterogeneous webserver infrastructure, which can include hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application. It takes only a single vulnerability to undermine the security of the entire infrastructure. In order to address these problems, it is of utmost importance to perform an indepth review of configuration and known security issues.\n\nThe following steps need to be taken to test the configuration management infrastructure:\n\nStep 1:\n The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.\n\nStep 2:\n All the elements of the infrastructure need to be reviewed in order to make sure that they don’t contain any known vulnerabilities.\n\nStep 3:\n A review needs to be made of the administrative tools used to maintain all the different elements.\n\nStep 4:\n The authentication systems, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.\n\nStep 5:\n A list of defined ports which are required for the application should be maintained and kept under change control.",
"002": "Configuration review and testing is a critical task in creating and maintaining an architecture. This is because many different systems will be usually provided with generic configurations that might not be suited to the task they will perform on the specific site they’re installed on.\n\n While the typical web and application server installation will contain a lot of functionality (like application examples, documentation, test pages) what is not essential should be removed before deployment to avoid post-install exploitation. \n\nCGI scanners include a detailed list of known files and directory samples that are provided by different web or application servers.\nAlso will event logs often contain data that is useful to an attacker (information leakage) or can be used directly in exploits.",
"003": "File extensions are commonly used in web servers to easily determine which technologies, languages and plugins must be used to fulfill the web request. \nWhile this behavior is consistent with RFCs and Web Standards, using standard file extensions provides the penetration tester useful information about the underlying technologies used in a web appliance. \n\n Determining how web servers handle requests corresponding to files having different extensions may help in understanding web server behavior depending on the kind of files that are accessed.\n\nThe following file extensions should never be returned by a web server, since they are related to files which may contain sensitive information:\n • .asa\n• .inc \n\n The following file extensions are related to files which, when accessed, are either displayed or downloaded by the browser. \n Therefore, files with these extensions must be checked to verify that they are indeed supposed to be served:\n• .zip, .tar, .gz, .tgz, .rar, ...: (Compressed) archive files\n• .java: No reason to provide access to Java source files\n• .txt: Text files\n• .pdf: PDF documents\n• .doc, .rtf, .xls, .ppt, ...: Office documents\n• .bak, .old and other extensions indicative of backup files \n\n To identify files having a given extensions a mix of techniques can be employed. \nThese techniques can include Vulnerability Scanners, spidering and mirroring tools, manually inspecting the application or querying search engines.",
"004": "An important source of vulnerability lies in files which have nothing to do with the application, but are created as a consequence of editing application files, or after creating on-the-fly backup copies, or by leaving in the web tree old files or unreferenced files.\n\n Theoretically the examination should be performed by hand to be thorough. However, since in most cases copies of files or backup files tend to be created by using the same naming conventions, the search can be easily scripted.",
"005": "Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.\n\nAn application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. \nSuch changes may include: \n• user account provisioning\n• site design and layout \n• data manipulation\n• configuration changes\n\nThe following describes vectors that may be used to test for the presence of administrative interfaces: \n• Directory and file enumeration \n• Brute forcing tools like THC-HYDRA \n• Comments and links in source code \n• Reviewing server and application documentation \n• Publicly available information (e.g. default passwords) \n• Alternative server port \n• Parameter tampering",
"006": "To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.\n\n Some of the HTTP methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following: \n• PUT: allows client to upload files to web server \n• DELETE: allwas client to delete files from web server \n• CONNECT: allows client to use web server as proxy \n• TRACE: echoes back to client whatever he sent to server",
"007": "The HTTP Strict Transport Security (HSTS) feature lets a web application to inform the browser, through the use of a special response header, that it should never establish a connection to the the specified domain servers using HTTP.\n\n The HTTP strict transport security header uses two directives: \n• max-age \n• includeSubDomains \n\nTesting for the presence of HSTS header can be done by checking for the existence of the HSTS header in the server’s response in an interception proxy, or by using curl.",
"008": "Rich Internet Applications (RIA) have adopted Adobe’s crossdomain.xml policy files to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. \nHowever, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks. \n\n To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application’s root, and from every folder found."
},
"ident": {
"001": "The objective is to validate the system roles defined within the application sufficiently define and separate each system and business role to manage appropriate access to system functionality and information. \n\n It is common in modern enterprises to define system roles to manage users and authorization to system resources. \nImportant to remember is that cold, hard authorization isn’t the only way to manage access to system objects. In more trusted environments where confidentiality is not critical, softer controls such as application workflow and audit logging can support data integrity requirements while not restricting user access to functionality.\n\n Either with or without the help of the system developers or administrators, develop an role versus permission matrix. The matrix should enumerate all the roles that can be provisioned and explore the permissions that are allowed.",
"002": "Some websites offer a user registration process that automates (or semi-automates) the provisioning of system access to users. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. \n\n Step 1: \n Verify that the identity requirements for user registration are aligned with business and security requirements. \n\n Step 2: \n Validate the registration process. \n\n Verify that the identity requirements for user registration are aligned with business and security requirements: \n• Can anyone register for access? \n• Are registrations vetted by a human? \n• Can the same person or identity register multiple times? \n• Can users register for different roles or permissions? \n• What proof of identity is required for a registration? \n• Are registered identities verified? \n\n Validate the registration process: \n • Can identity information be easily forged or faked? \n • Can the exchange of identity information be manipulated?",
"003": "Verify which accounts may provision other accounts and of what type. \n\n The provisioning of accounts presents an opportunity for an attacker to create a valid account without application of the proper identification and authorization process.\nDetermine which roles are able to provision users and what sort of accounts they can provision.",
"004": "The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. \nThis test will be useful for brute force testing, in which the tester verifies if, given a valid username, it is possible to find the corresponding password. \n\nIn some cases, a message is received that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, testers can enumerate the existing users by sending a username and an empty password. \n If the application is vulnerable, the tester receives a response message that reveals, directly or indirectly, some information useful for enumerating users.",
"005": "The objective is to determine whether a consistent account name structure renders the application vulnerable to account enumeration. Determine whether the application’s error messages permit account enumeration. \n\n User account names are often highly structured (e.g. Joe Bloggs account name is jbloggs and Fred Nurks account name is fnurks) and valid account names can easily be guessed. \n • Determine the structure of account names.\n• Evaluate the application’s response to valid and invalid account names.\n• Use different responses to valid and invalid account names to enumerate valid account names.\n• Use account name dictionaries to enumerate valid account names.",
"006": "Guest and Training accounts are useful ways to acquaint potential users with system functionality prior to them completing the authorisation process required for access. \n Evaluate consistency between access policy and guest/training account access permissions.",
"007": "Verify the identity requirements for user registration align with business/security requirements. \n\nValidate the registration process."
},
"authn": {
"001": "The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. \n\n Testing for credentials transport means verifying that the user’s\nauthentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. \n\n You can use WebScarab or any web proxy in order to capture packet headers and to inspect them. \n Check if HTTPS is used in every sensitive request, like those in log in pages, to prevent unauthorized users to intercept the data.",
"002": "Often are applications, once installed, not properly configured and the default credentials provided for initial authentication and configuration are never changed. \n\n When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can find common credentials using a search engine or by using one of the sites or tools listed in the Reference section. \n\n When facing applications where we do not have a list of default and common user accounts we can attempt to guess valid default credentials. \n Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. \n\nSince these types of default credentials are often bound to administrative accounts you can try the following usernames for the start: \n• admin \n• administrator \n• root \n• system \n• guest \n• operator \n• super",
"003": "Account lockout mechanisms are used to mitigate brute force password guessing attacks. Accounts are typically locked after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. \n\n Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing or can afford to lock: \n\n Step 1: \n Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing. \n\n Step 2: \nEvaluate the unlock mechanism’s resistance to unauthorized account unlocking. \n\n Without a strong lockout mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to: \n• Confidential information or data \n• Administration panels \n• Opportunities for further attacks",
"004": "While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. \n\n There are several methods of bypassing the authentication schema that is used by a web application: \n• Direct page request (forced browsing) \n• Parameter modification \n• Session ID prediction \n• SQL Injection",
"005": "Browsers will sometimes ask a user if they wish to remember the password that they just entered. \n\n Having the browser store passwords is not only a convenience for end-users, but also for an attacker. If an attacker can gain access to the victim’s browser (e.g. XSS attack), then they can retrieve the stored passwords. \n Additionally where custom “remember me” functions are put in place weaknesses in how the token is stored on the client PC could expose the users passwords. \n\n Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in cookies: \n• Look for passwords stored in cookie \n• Examine the hashing mechanism \n• Verify that credentials are only send during login \n• Consider sensitive form fields",
"006": "Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn’t need to be downloaded again. \n If sensitive information is displayed to the user, then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser’s cache or by simply pressing the browser’s “Back” button. \n\n Technically, the “Back” button is a history and not a cache. The cache and the history are two different entities. However, they share the same weakness of presenting previously displayed sensitive information. \n\nThe “Back” button can be stopped from showing sensitive data. \nThis can be done by: \n• Delivering the page over HTTPS. \n• Setting Cache-Control: must-re-validate",
"007": "The most prevalent and most easily administered authentication mechanism is a static password. It is lamented that most common passwords are still: 123456, password and qwerty. \n\nDetermine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords. \n\n Step 1: \n What characters are permitted and forbidden for use within a password? \nIs the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols? \n\n Step 2: \n How often can a user change their password? \nHow quickly can a user change their password after a previous change? \n Users may bypass password history requirements by changing their password 5 times in a row. \n\n Step 3: \n When must a user change their password? \nAfter 90 days? \nAfter account lockout due to excessive log on attempts? \n\n Step 4: \n How often can a user reuse a password? \n Does the application maintain a history of the user’s previous used 8 passwords? \n\n Step 5: \n How different must the next password be from the last password? \n\n Step 6: \nIs the user prevented from using his username or other account information (such as first or last name) in the password?",
"008": "Often called “secret” questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of the password. \n\n They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may allow the user to generate their own question and answer pairs. \n Both methods are prone to insecurities. Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable. \n\n The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding the answers. \n\n Step 1: \nTry to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process.\n\n Step 2: \n Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties.\nIf the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. \n\n Step 3: \n Determine if a number of incorrectly supplied security answers trigger a lockout mechanism.",
"009": "The password change and reset function of an application is a self-service password change or reset mechanism for users. \n This self-service mechanism allows users to quickly change or reset their password without an administrator intervening. \n\n Step 1: \n Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account. \n\n Step 2: \nDetermine the resistance of the passwords reset functionality against guessing or bypassing. \n\n For both password change and password reset it is important to check.. \n\n.. if users, other than administrators, can change or reset passwords for accounts other than their own. \n.. if users can manipulate or subvert the password change or reset process. \n.. if the password change or reset process is vulnerable to CSRF.",
"010": "Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. \n\n Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities. \n Some of these channels may themselves be separate web applications using different host names or paths. For example: \n• Standard website \n• Mobile website \n• Accessibility optimized website \n• Parallel websites that utilize same user accounts \n• Development, UAT and versions of the standard website \n\n But they could also be other types of application or business processes: \n• Mobile device app \n• Desktop application \n• Call center operators \n• Interactive voice response or phone tree systems"
},
"authz": {
"001": "Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands. \n\n In web servers and web applications, this kind of problem arises in path traversal/file include attacks. During an assessment, to discover path traversal and file include flaws, testers need to perform two different stages: \n\n Stage 1: \n Input Vectors Enumeration (a systematic evaluation of each input vector) \n\n Stage 2: \n Testing Techniques (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability) \n\n The next stage of testing is analyzing the input validation functions present in the web application. Using the previous example, the dynamic page called getUserProfile.jsp loads static information from a file and shows the content to users. An attacker could insert the malicious string “../../../../etc/passwd” to include the password hash file. \n It’s a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first the test string isn’t successful, try another encoding scheme.",
"002": "This kind of test focuses on verifying how the authorization schema has been implemented for each role or privilege to get access to reserved functions and resources. \n\nFor every specific role the tester holds during the assessment, for every function and request that the application executes during the post-authentication phase, it is necessary to verify: \n • Is it possible to access that resource even if the user is not authenticated? \n • Is it possible to access that resource after the log-out? \n • Is it possible to access functions and resources that should be accessible to a user that holds a different role or privilege? \n\n Try to access the application as an administrative user and track all the administrative functions: \n • Is it possible to access administrative functions also if the tester is logged as a user with standard privileges?\n• Is it possible to use these administrative functions as a user with adifferent role and for whom that action should be denied?",
"003": "Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed. \n\n During this phase, the tester should verify that it is not possible for a user to modify his or her privileges or roles inside the application in ways that could allow privilege escalation attacks. \n The degree of escalation depends on what privileges the attacker is authorized to possess, and what privileges can be obtained in a successful exploit. \n\n In every portion of the application where a user can create information in the database (e.g., making a payment, or sending a message), can receive information (statement of account, order details, etc.), or delete information (drop user, messages, etc.), it is necessary to record that functionality. \n Try to access such functions as another user in order to verify if it is possible to access a function that should not be permitted by the user’s role/privilege.",
"004": "Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. \n As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. \n\n Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. \n\n To test for this vulnerability the tester first needs to map out all locations in the application where user input is used to reference objects directly. \n The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions. \n By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user."
},
"sess": {
"001": "In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. \n These mechanisms are known as Session Management. \n\n In this test, the tester wants to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users. \n Due to the importance of the data that they store, cookies are there fore vital in the overall security of the application. In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. \n\n Usually the main steps of the attack pattern are the following: \n• cookie collection \n• cookie reverse engineering \n• cookie manipulation \n\n Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application.",
"002": "Cookies are often a key attack vector for malicious users and the application should always take due diligence to protect cookies. This section looks at how an application can take the necessary precautions when assigning cookies, and how to test that these attributes have been correctly configured. \n\n Due to the sensitive nature of information in cookies, they are typically encoded or encrypted in an attempt to protect the information they contain. \n Once the tester has an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance, they should take a look at what attributes can be set for a cookie and how to test if they are secure. \n\nBy using an intercepting proxy or traffic intercepting browser plugin, trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:\n• Secure Attribute\n• HttpOnly Attribute\n• Domain Attribute\n• Path Attribute\n• Expires Attribute",
"003": "When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).\n\n Session fixation vulnerabilities occur when..\n .. a web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user \n.. an attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session. \n\n In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user’s account through the active session.",
"004": "The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. It is important that they are protected from eavesdropping at all times, particularly whilst in transit between the client browser and the application servers. \n\n Using a personal proxy, it is possible to ascertain the following about each request and response: \n • Protocol used (e.g., HTTP vs. HTTPS) \n • HTTP Headers \n • Message Body (e.g., POST or page content) \n\n Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunneling or encryption. If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk. It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used. \n\n Every time the authentication is successful, the user should expect to receive: \n• A different session token \n• A token sent via encrypted channel for every HTTP Request ",
"005": "CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated.\nA successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application. \n CSRF relies on the following: \n\n Point 1: \n Web browser behavior regarding the handling of session-related information such as cookies and http authentication information; \n\n Point 2: \n Knowledge by the attacker of valid web application URLs; \n\n Point 3: \n Application session management relying only on information which is known by the browser; \n\n Point 4: \n Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag img \n\n The tester must know URLs in the restricted (authenticated) area. If they possess valid credentials, they can assume both roles – the attacker and the victim. In this case, testers know the URLs to be tested just by browsing around. \n\n If session management relies only on client side values (information available to the browser), then the application is vulnerable. \n For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user.",
"006": "Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. \n\n A secure session termination requires at least the following components: \n • Availability of user interface controls that allow the user to manually log out \n • Session termination after a given amount of time without activity (session timeout) \n • Proper invalidation of server-side session state \n\n The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability.",
"007": "In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache. \n\n The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. Session timeout management and expiration must be enforced server-side. If some data under the control of the client is used to enforce the session timeout, an attacker could manipulate these to extend the session duration. \n\n Step 1: \nTesters have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable. \n\n Step 2: \n If the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server. \n\n As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.",
"008": "Session Variable Overloading (Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to.. \n.. bypass efficient authentication enforcement mechanisms, and impersonate legitimate users. \n.. elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof. \n.. skip over qualifying phases in multi-phase processes, even if the process includes code level restrictions. \n.. manipulate server-side values in indirect methods that cannotbe predicted or detected. \n.. execute traditional attacks in locations that were previously unreachable, or even considered secure. \n\n This vulnerability occurs when an application uses the same session variable for more than one purpose. It can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points."
},
"inpval": {
"001": "Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. \nThe injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. \nThe attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim. One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. \n In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out “<script>”, but might not filter %3cscript%3e which simply includes another encoding of tags. A test will include at least three phases: \n\n Phase 1: \nDetect input vectors. For each web page, the tester must determine all the web application’s user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. \n\n Phase 2: \n Analyze each input vector to detect potential vulnerabilities. dTo detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually. \n\n Phase 3: \n For each test input attempted in the previous phase, the tester will analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application’s security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out.",
"002": "Stored Cross-site Scripting (XSS) is the most dangerous type of Cross Site Scripting. \n\n Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application. \n\n A successful exploitation occurs when a user visits a page with a stored XSS.\nThe following phases relate to a typical stored XSS attack scenario: \n • Attacker stores malicious code into the vulnerable page \n • User authenticates in the application \n • User visits vulnerable page \n • Malicious code is executed by the user’s browser \n\n This vulnerability can be used to conduct a number of browser-based attacks including: \n • Hijacking another user’s browser \n • Capturing sensitive information viewed by application users \n • Pseudo defacement of the application \n • Port scanning of internal hosts \n • Directed delivery of browser-based exploits \n • Other malicious activities",
"003": "The HTTP specification includes request methods other than the standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers. \n\n As the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. \n\n The full HTTP 1.1 specification defines the following valid HTTP request methods, or verbs: \n • OPTIONS \n • GET \n • HEAD \n • POST \n • PUT \n • DELETE \n • TRACE \n • CONNECT \n\n If enabled, the Web Distributed Authoring and Version (WebDAV) extensions permit several more HTTP methods: \n • PROPFIND \n • PROPPATCH \n • MKCOL \n • COPY \n • MOVE \n • LOCK \n • UNLOCK",
"004": "Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors or modify internal variables values. As HTTP Parameter Pollution (in short HPP) affects a building block of all web technologies, server and client side attacks exist. \n\n Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. \n However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. \n Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components.",
"005": "SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands. \n\n The tester can supply crafted input trying to make the original SQL statement execute further actions of the testers’s choice. \n As an example the tester could change a statement to “$password = 1’ or ‘1’ = ‘1”, changing the logic of the SQL statement, modifying the WHERE clause adding a condition “or ‘1’ = ‘1” \n\n SQL Injection attacks can be divided into the following three classes: \n • Inband \n • Out-of-band \n • Inferential or Blind \n\n About the techniques to exploit SQL injection flaws there are five commons techniques. Also those techniques sometimes can be used in a combined way: \n • Union Operator \n • Boolean \n • Error based \n • Out-of-band \n • Time delay",
"005_1": "Web based PL/SQL applications are enabled by the PL/SQL Gateway, which is is the component that translates web requests into database queries. Oracle has developed a number of software implementations. \n Products that use the PL/SQL Gateway include, but are not limited to, the Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB and Oracle Application Server. \n\n Essentially the PL/SQL Gateway simply acts as a proxy server taking the user’s web request and passes it on to the database server where it is executed. \n\n Step 1: \n The web server accepts a request from a web client and determines if it should be processed by the PL/SQL Gateway. \n\n Step 2: \n The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables. \n\n Step 3: \n The requested package and procedure are wrapped in a block of anonymous PL/SQL, and sent to the database server. \n\n Step 4: \n The database server executes the procedure and sends the results back to the Gateway as HTML \n\n Step 5: \n The gateway sends the response, via the web server, back to the client. \n\n Understanding this point is important - the PL/SQL code does not exist on the web server but, rather, in the database server. \n This means that any weaknesses in the PL/SQL Gateway or any weaknesses in the PL/SQL application, when exploited, give an attacker direct access to the database server.",
"005_2": "SQL Injection vulnerabilities occur whenever input is used in the construction of a SQL query without being adequately constrained or sanitized. \n MySQL server has a few particularities so that some exploits need to be specially customized for this application. \n\n When an SQL injection vulnerability is found in an application backed by a MySQL database, there are a number of attacks that could be performed depending on the MySQL version and user privileges on DBMS. \n\n MySQL comes with at least four versions which are used in production worldwide. Every version has a set of features proportional to version number: \n • From Version 4.0: UNION \n • From Version 4.1: Subqueries \n • From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA \n • From Version 5.0.2: Triggers \n\n It should be noted that for MySQL versions before 4.0.x, only Boolean or time-based Blind Injection attacks could be used, since the subquery functionality or UNION statements were not implemented.",
"005_3": "SQL injection allows an attacker to access the SQL servers and execute SQL code under the privileges of the user used to connect to the database. SQL Injection techniques for Microsoft SQL Server utilize specific features. \n\n As explained in SQL injection, a SQL-injection exploit requires two things: an entry point and an exploit to enter. \n Any user-controlled parameter that gets processed by the application might be hiding a vulnerability. This includes: \n • Application parameters in query strings (e.g., GET requests) \n • Application parameters included as part of the body of a POST request \n • Browser-related information (e.g., user-agent, referrer) \n • Host-related information (e.g., host name, IP) \n • Session-related information (e.g., user ID, cookies) \n\n Some Microsoft SQL Server operators and commands are: \n • comment operator -- \n • query separator ; \n\n Useful stored procedures include: \n • xp_cmdshell \n • xp_regread \n • xp_regwrite \n • sp_configure \n • sp_ makewebtask \n • sp_sendmail",
"005_4": "When a SQL Injection has been found, you need to carefully fingerprint the backend database engine. You can determine that the backend database engine is PostgreSQL by using the :: cast operator. \n In addition, the function version() can be used to grab the PostgreSQL banner. This will also show the underlying operating system type and version. \n\n SQL Injection techniques for PostgreSQL have the following characteristics: \n • PHP Connector allows multiple statements to be executed by using ; as a statement separator \n • SQL Statements can be truncated by appending the comment char: -- \n • LIMIT and OFFSET can be used in a SELECT statement to retrieve a portion of the result set generated by the query \n\n For blind SQL injection attacks, you should take into consideration the following built-in functions: \n • String Length - LENGTH(str) \n • Extract a substring from a given string - SUBSTR(str,index,offset) \n • String representation with no single quotes - CHR(101)||CHR(108)||CHR(111)",
"005_5": "Microsoft Access can utilize specific features for SQL injection techniques. \n Unfortunately, MS Access doesn’t support typical operators that are traditionally used during SQL injection testing, including: \n• No comments characters\n• No stacked queries\n• No LIMIT operator\n• No SLEEP or BENCHMARK alike operators\n• and many others \n\n Still, there are also many other functions that can be used while testing SQL injection, including but not limited to: \n • ASC: Obtain the ASCII value of a character passed as input \n • CHR: Obtain the character of the ASCII value passed as input \n • LEN: Return the length of the string passed as parameter \n • IIF: Is the IF construct, e.g. IIF(1=1, ‘a’, ‘b’) return ‘a’ \n • MID: This function allows you to extract substring \n • TOP: This function allows you to specify the max. number of results \n • LAST: This function is used to select only the last row of a set \n\n Various system tables exist by default in MS Access that can be potentially used to obtain table names and columns. \n Unfortunately, in the default configuration of recent MS Access database releases, these tables are not accessible. Nevertheless, it is always worth trying: \n • MSysObjects \n • MSysACEs \n • MSysAccessXML",
"005_6": "NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. \n But because these NoSQL injection attacks may execute within a procedural language , rather than in the declarative SQL language, the potential impacts are greater than traditional SQL injection. \n\n NoSQL database calls are written in the application’s programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). \n\n Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call. \n Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing. \n\n There are now over 150 NoSQL databases available, but at the time of writing MongoDB is the most widely used NoSQL database. \n\n The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters. \n For example if an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query.",
"006": "The Lightweight Directory Access Protocol (LDAP) is used to store information about users, hosts, and many other objects. LDAP injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions. \n A web application could use LDAP in order to let users authenticate or search other users’ information inside a corporate structure. \n\n The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.\n [Rfc2254] defines a grammar on how to build a search filter on LDAPv3 and extends [Rfc1960] (LDAPv2). \nAn LDAP search filter is constructed in Polish notation, also known as [prefix notation]. \n\n A successful exploitation of an LDAP injection vulnerability could allow the tester to: \n • Access unauthorized content \n • Evade application restrictions \n • Gather unauthorized informations \n • Add or modify Objects inside LDAP tree structure",
"007": "ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack.\nHowever, the injection vulnerability exists in code generated by the ORM tool. \n\n An ORM is an Object Relational Mapping tool.\nIt is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects, and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases, a variant of SQL, to perform CRUD operations on a database. \n\n ORM tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. \n\n ORM Injection vulnerabilities is identical to SQL Injection testing. In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. \n Most ORM tools provide safe functions to escape user input.\nHowever, if these functions are not used, and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack. \n\n Patterns to look for in code include: \n • Input parameters concatenated with SQL strings",
"008": "XML Injection testing is when a tester tries to inject an XML doc to the application. If the XML parser fails to contextually validate data, then the test will yield a positive result. \n\n Step 1: \n In order to test an application for the presence of a XML Injection vulnerability consists of trying to insert XML metacharacters. \n\n XML metacharacters are: \n • Single quote: ‘ \n • Double quote: “ \n • Angular parentheses: > and < \n • Comment tag: <!--/--> \n • Ampersand: & \n • CDATA section delimiters: <![CDATA[ / ]]> \n\n Another test is related to CDATA tag. Suppose that the XML document is processed to generate an HTML page. In this case, the CDATA section delimiters may be simply eliminated, without further inspecting their contents. Then, it is possible to inject HTML tags, which will be included in the generated page, completely bypassing existing sanitization routines. \n\n Step 2: \n Once the first step is accomplished, the tester will have some information about the structure of the XML document. Then, it is possible to try to inject XML data and tags (Tag Injection).",
"009": "Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages. This feature is incarnated by the Server-Side Includes (SSI). \nIn SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution. \n\n With regard to SSI injection, the attacker could provide input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. \n\n Step 1: \n What we need find is if the web server actually supports SSI directives. To find out we just need to discover which kind of web server is running on our target. \n Hint: If the site contains .shtml files, then SSI are probably supported, as this extension is used to identify pages containing these directives. \n\n Step 2: \n The next step consists of determining if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code. \n We need to find every page where the user is allowed to submit some kind of input, and verify whether the application is correctly validating the submitted input. \n If sanitization is insufficient, we need to test if we can provide data that is going to be displayed unmodified. \n Besides common user-supplied data, input vectors that should always be considered are HTTP request headers and cookies content. \n\n Step 3: \n Once we have a list of potential injection points, we can check how the input is handled, what kind of filtering is performed, what characters the application is not letting through, and how many types of encoding are taken into account.",
"010": "Web applications heavily use databases to store and access the data they need for their operations. \n Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language. \n\n XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject XPath syntax into a request interpreted by the application, allowing an attacker to execute user-controlled XPath queries. \n XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the characteristics of the SQL dialect used by the target database. \n\n The XPath attack pattern is very similar to the usual SQL Injection and as in a common SQL Injection attack, with XPath injection, the first step is to insert a single quote (‘) in the field to be tested, introducing a syntax error in the query, and to check whether the application returns an error message.",
"011": "This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not being properly sanitized. \n\n An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the front-end web servers.Therefore, mail server results may be more vulnerable to attacks by end users. \n\n The standard attack patterns are: \n • Identifying vulnerable parameters \n • Understanding the data flow and deployment structure of the client \n • IMAP/SMTP command injection \n\n This last stage has two possible outcomes: \n\n Outcome 1: \n The injection is possible in an unauthenticated state: The affected functionality does not require the user to be authenticated. \n The injected (IMAP) commands available are limited to: \nCAPABILITY, NOOP, AUTHENTICATE, LOGIN, and LOGOUT. \n\n Outcome 2: \n The injection is only possible in an authenticated state: the successful exploitation requires the user to be fully authenticated before testing can continue. \n\n In any case, the typical structure of an IMAP/SMTP Injection is as follows: \n • Header: ending of the expected command; \n • Body: injection of the new command; \n • Footer: beginning of the expected command.",
"012": "In Code Injection testing, a tester submits input that is processed by the web server as dynamic code or as an included file. These tests can target various server-side scripting engines, e.g.., ASP or PHP. Proper input validation and secure coding practices need to be employed to protect against these attacks. \n\n Testing for PHP Injection vulnerabilities \n Using the querystring, the tester can inject code to be processed as part of the included file. The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file. \n\n Testing for ASP Code Injection vulnerabilities \n Examine ASP code for user input used in execution functions.\nCan the user enter commands into the Data input field?",
"012_1": "The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation. \n\n This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to: \n • Code execution on the web server \n • Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS) \n • Denial of Service (DoS) \n • Sensitive Information Disclosure \n\n Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures. \n Since LFI occurs when paths passed to “include” statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters.",
"012_2": "The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation. \n\n This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to: \n • Code execution on the web server \n • Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS) \n • Denial of Service (DoS) \n • Sensitive Information Disclosure \n\n Remote File Inclusion (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures. \n\n Since RFI occurs when paths passed to “include” statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters.",
"013": "OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized s subject to this exploit. \n\n When viewing a file in a web application, the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the file name. \n Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon.",
"014": "Different types of buffer overflow vulnerabilities have different testing methods. Here are the testing methods for the common types of buffer overflow vulnerabilities. \n\n • Testing for heap overflow vulnerability \n • Testing for stack overflow vulnerability \n • Testing for format string vulnerability",
"014_1": "In this test the penetration tester checks whether a they can make a Heap overflow that exploits a memory segment. \n\n Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information. \n\n When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. \n\n There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. \n\n The key is to supply as input strings that are longer than expected. Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow, an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. \n When debugging a windows program, a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. \n\n Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.",
"014_2": "Stack overflows occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking. \n Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. \n\n In fact almost every platform is vulnerable to stack overflows with the following notable exceptions: \n • J2EE – as long as native methods or system calls are not invoked \n • .NET – as long as /unsafe or unmanaged code is not invoked \n • PHP – as long as external programs and vulnerable extensions are not called \n\n Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. \n\n The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected. \n However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. \n Therefore, the steps required to locate and validate stack overflows would be to attach a debugger to the target application or process, generate malformed input for the application, subject the application to malformed input, and inspect responses in a debugger.",
"014_3": "Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc. Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc. \n The vulnerability arises when format functions are called with inadequate parameters validation and user controlled data. \n\n A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such as %s, %n, %x to the application by means of command line argument argv[1]. \n\n This situation tends to become precarious since a user who can supply format specifiers can perform the following malicious actions:\n • Enumerate Process Stack \n • Control Execution Flow \n • Denial of Service \n\n The key to testing format string vulnerabilities is supplying format type specifiers in application input. \n\n Format string vulnerabilities manifest mainly in web servers, application servers, or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases, an error reporting or logging function like syslog( ) has been called insecurely. \n When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. \n\n While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. \n The functions that are primarily responsible for format string vulnerabilities are ones that treat format specifiers as optional. Therefore when manually reviewing code, emphasis can be given to functions such as: \n • printf \n • fprintf \n • sprintf \n • snprintf \n • vfprintf \n • vprintf \n • vsprintf \n • vsnprintf",
"015": "Also often refered to as persistent attacks, incubated testing is a complex testing method that needs more than one data validation vulnerability to work. \n Incubated vulnerabilities are typically used to conduct “watering hole” attacks against users of legitimate web applications. \n\n Incubated vulnerabilities have the following characteristics: \n\n Firstly: \n The attack vector needs to be persisted in the first place, it needs to be stored in the persistence layer, and this would only occur if weak data validation was present or the data arrived into the system via another channel such as an admin console or directly via a backend batch process. \n\n Secondly: \n Once the attack vector was “recalled” the vector would need to be executed successfully. For example, an incubated XSS attack would require weak output validation so the script would be delivered to the client in its executable form. \n\n Exploitation of some vulnerabilities, or even functional features of a web application, will allow an attacker to plant a piece of data that will later be retrieved. \n In a penetration test, incubated attacks can be used to assess the criticality of certain bugs that usually will be used to target a large number of victims at the same time. \n\n This type of asynchronous attack covers a great spectrum of attack vectors, among them the following: \n • File upload components in a web application \n • Cross-site scripting issues in public forums posts \n • SQL/XPATH Injection allowing the attacker to upload content to a database \n • Misconfigured servers allowing installation of packages or components \n\n Step 1: \n Verify the content type allowed to upload to the web application and the resultant URL for the uploaded file. \n\n Step 2: \n Upload a file that will exploit a component in the local user workstation when viewed or downloaded by the user. \n\n Step 3: \n Send your victim an email or other kind of alert in order to lead him/her to browse the page. \n\n The expected result is the exploit will be triggered when the user browses the resultant page or downloads and executes the file from the trusted site.",
"016": "There are two different attacks that target specific HTTP headers:\n• HTTP splitting\n• HTTP smuggling \n\n The first attack exploits a lack of input sanitization which allows an intruder to insert CR and LF characters into the headers of the application response and to ‘split’ that answer into two different HTTP messages. \n The goal of the attack can vary from a cache poisoning to cross site scripting. \n\n In the second attack, the attacker exploits the fact that some specially crafted HTTP messages can be parsed and interpreted in different ways depending on the agent that receives them.\nHTTP smuggling requires some level of knowledge about the different agents that are handling the HTTP messages (web server, proxy, firewall). \n\n HTTP Splitting \n Some web applications use part of the user input to generate the values of some headers of their responses. The most straightforward example is provided by redirections in which the target URL depends on some user-submitted value. \n The headers that are the most likely candidates for this attack are:\n• Location\n• Set-Cookie \n\n HTTP Smuggling\n This leverages the different ways that a particularly crafted HTTP message can be parsed and interpreted by different agents (browsers, web caches, application firewalls)."
},
"err": {
"001": "Often, during a penetration test on web applications, we come up against many error codes generated from applications or web servers.\n It’s possible to cause these errors to be displayed by using a particular requests, either specially crafted with tools or created manually. These codes are very useful to penetration testers during their activities, because they reveal a lot of information about databases, bugs, and other technological components directly linked with web applications. \n\n A good collection of error information can facilitate assessment efficiency by decreasing the overall time taken to perform the penetration test. \n Attackers sometimes use search engines to locate errors that disclose information. Searches can be performed to find any erroneous sites as random victims, or it is possible to search for errors in a specific site using the search engine filtering tools. \n\n Below are some areas listed that could return detailed error messages to the user. Each of the areas has specific information about the operating system, application version, etc. \n • Web Server Errors (HTTP Responses) \n • Application Server Errors (Framework messages) \n • Database Errors (Database System messages)",
"002": "Stack traces are not vulnerabilities by themselves, but they often reveal information that is interesting to an attacker. Attackers attempt to generate these stack traces by tampering with the input to the web application with malformed HTTP requests and other input data. \n\n If the application responds with stack traces that are not managed it could reveal information useful to attackers. This information could then be used in further attacks. \n\n There are a variety of techniques that will cause exception messages to be sent in an HTTP response. Note that in most cases this will be an HTML page, but exceptions can be sent as part of SOAP or REST responses too. \nSome tests to try include: \n • invalid input \n • input that contains non alphanumeric chars or query syntax \n • empty inputs \n • inputs that are too long \n • access to internal pages without authentication \n • bypassing application flow \n\n All the above tests could lead to application errors that may contain stack traces. It is recommended to use a fuzzer in addition to any manual testing. \n\n When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist: \n • SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured \n • Certificate validity must be ensured"
},
"crypst": {
"001": "Sensitive data must be protected when it is transmitted through the network. \nAs a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. \n\n Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. \n\n HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. \n Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. \n\n Common Issues: \n When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist: \n • SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured \n • Certificate validity must be ensured \n • Software exposed must be updated due to possibility of known vulnerabilities \n • Usage of Secure flag for Session Cookies \n • Usage of HTTP Strict Transport Security (HSTS) \n • The presence of HTTP and HTTPS both, which can be used to intercept traffic \n • The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information \n\n Testing for sensitive data transmitted in clear-text \n A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers. \n\n Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities \n The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. At the time of writing these criteria are widely recognized a checklist: \n • Weak ciphers must not be used (e.g. less than 128 bits) \n • No NULL ciphers suite, due to no encryption used \n • Weak protocols must be disabled (e.g. SSLv2 must be disabled) \n • Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled) \n • No Export (EXP) level cipher suites, due to can be easly broken \n • X.509 certificates key length must be strong \n • X.509 certificates must be signed only with secure hashing algoritms \n • Keys must be generated with proper entropy \n • Secure Renegotiation should be enabled. \n • MD5 should not be used, due to known collision attacks \n • RC4 should not be used, due to crypto-analytical attacks \n • Server should be protected from BEAST Attack \n • Server should be protected from CRIME attack, TLS compression must be disabled \n • Server should support Forward Secrecy",
"002": "A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. \n\n The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. \n\n Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn’t match a multiple of the block size of the used cipher has to be padded in a specific manner so the decryptor is able to strip the padding. \n\n The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. \n A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. \n\n First the possible input points for padding oracles must be identified. Generally the following conditions must be met: \n\n Condition 1: \n The data is encrypted. Good candidates are values which appear to be random. \n\n Condition 2: \n A block cipher is used. The length of the decoded (e.g. Base64) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts share a common divisor in the length. \n\n If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. \n The tests and the base value should at least cause three different states while and after decryption: \n • Cipher text gets decrypted, resulting data is correct \n • Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic \n • Cipher text decryption fails due to padding errors \n\n Search especially for exceptions and messages which state that something is wrong with the padding. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability that there is a padding oracle present at this point. Examples: \n • ASP.NET throws “System.Security.Cryptography.Cryptographic Exception: Padding is invalid and cannot be removed.” \n • In Java a javax.crypto.BadPaddingException is thrown in this case \n • Decryption errors or similar can be possible padding oracles",
"003": "Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanism must not have limitations or vulnerabilities. \n\n As a rule of thumb if data must be protected when it is stored, this data must also be protected during transmission. \n Some examples for sensitive data are: \n • Information used in authentication (e.g. Credentials, PINs, Tokens, Cookies…) \n • Information protected by laws, regulations or specific organizational policy (e.g. Credit Cards, Customers data) \n\n Various types of information that must be protected, could be transmitted by the application in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS, or whether weak cyphers are used. \n\n 1. Basic Authentication over HTTP \n A typical example is the usage of Basic Authentication over HTTP. When using Basic Authentication, user credentials are encoded rather than encrypted, and are sent as HTTP headers. \n\n 2. Form-Based Authentication Performed over HTTP \n Another typical example is authentication forms which transmit user authentication credentials over HTTP. It is possible to see this issue by examining the HTTP traffic with an interception proxy. \n\n 3. Cookie Containing Session ID Sent over HTTP \n The Session ID Cookie must be transmitted over protected channels. If the cookie does not have the secure flag set it is permitted for the application to transmit it unencrypted."
},
"buslogic": {
"001": "The application must ensure that only logically valid data can be entered at the front end as well as directly to the server side of an application of system. Only verifying data locally may leave applications vulnerable to server injections through proxies or at handoffs with other systems. This is different from simply performing Boundary Value Analysis (BVA) in that it is more difficult and in most cases cannot be simply verified at the entry point, but usually requires checking some other system. \n\n Vulnerabilities related to business data validation is unique in that they are application specific and different from the vulnerabilities related to forging requests in that they are more concerned about logical data as opposed to simply breaking the business logic workflow. \n\n The front end and the back end of the application should be verifying and validating that the data it has, is using and is passing along is logically valid. Even if the user provides valid data to an application the business logic may make the application behave differently depending on data or circumstances. \n\n Generic Test Method \n • Review the project documentation and use exploratory testing looking for data entry points or hand off points between systems or software \n • Once found try to insert logically invalid data into the application/system \n\n Specific Testing Method \n • Perform front-end GUI Functional Valid testing on the application to ensure that the only “valid” values are accepted. \n • Using an intercepting proxy observe the HTTP POST/GET looking for places that variables such as cost and quality are passed. Specifically, look for “hand-offs” between application/systems that may be possible injection of tamper points. \n • Once variables are found start interrogating the field with logically “invalid” data, such as social security numbers or unique identifiers that do not exist or that do not fit the business logic. \n This testing verifies that the server functions properly and does not accept logically invalid data them.",
"002": "Forging requests is a method that attackers use to circumvent the front end GUI application to directly submit information for back end processing. The goal of the attacker is to send HTTP POST/GET requests through an intercepting proxy with data values that is not supported, guarded against or expected by the applications business logic. \n\n Vulnerabilities related to the ability to forge requests is unique to each application and different from business logic data validation in that it s focus is on breaking the business logic workflow. \n\n The application must be smart enough and designed with business logic that will prevent attackers from predicting and manipulating parameters to subvert programmatic or business logic flow, or exploiting hidden/undocumented functionality such as debugging. \n\n Generic Testing Method \n • Review the project documentation and use exploratory testing looking for guessable, predictable or hidden functionality of fields. \n • Once found try to insert logically valid data into the application/system allowing the user go through the application/system against the normal busineess logic workflow. \n\n Specific Testing Method 1 \n • Using an intercepting proxy observe the HTTP POST/GET looking for some indication that values are incrementing at a regular interval or are easily guessable. \n • If it is found that some value is guessable this value may be\nchanged and one may gain unexpected visibility. \n\n Specific Testing Method 2 \n • Using an intercepting proxy observe the HTTP POST/GET looking for some indication of hidden features such as debug that can be switched on or activated. \n • If any are found try to guess and change these values to get a different application response or behavior.",
"003": "Many applications are designed to display different fields depending on the user of situation by leaving some inputs hidden.\nHowever, in many cases it is possible to submit values hidden field values to the server using a proxy. In these cases the server side controls must be smart enough to perform relational or server side edits to ensure that the proper data is allowed to the server based on user and application specific business logic. \n\n Additionally, the application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing because these fields remain non-editable only in the context of the browsers. Users may be able to edit their values using proxy editor tools and try to manipulate business logic. \n\nBusiness logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to write or update/edit specific artifacts at specific times per the business process logic.\nThe application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. \n\n Generic Testing Method \n • Review the project documentation and use exploratory testing looking for parts of the application/system (i.e. input fields, databases or logs) that move, store or handle data/information. \n • For each identified component determine what type of data/information is logically acceptable and what types the application/system should guard against. Also, consider who according to the business logic is allowed to insert, update and delete data/information and in each component. \n • Attempt to insert, update or edit delete the data/information values with invalid data/information into each component (i.e. input, database, or log) by users that should not be allowed per the business logic workflow. \n\n Specific Testing Method 1 \n • Using a proxy capture and HTTP traffic looking for hidden fields. \n • If a hidden field is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to. \n\n Specific Testing Method 2 \n • Using a proxy capture and HTTP traffic looking a place to insert information into areas of the application that are non-editable. \n • If it is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to. \n\n Specific Testing Method 3 \n • List components of the application or system that could be edited, for example logs or databases. \n • For each component identified, try to read, edit or remove its information. For example log files should be identified and Testers should try to manipulate the data/information being collected.",
"004": "It is possible that attackers can gather information on an application by monitoring the time it takes to complete a task or give a respond. \n Additionally, attackers may be able to manipulate and break designed business process flows by simply keeping active sessions open and not submitting their transactions in the “expected” time frame. \n\n Process timing logic vulnerabilities is unique in that these manual misuse cases should be created considering execution and transaction timing that are application/system specific. \nProcessing timing may give/leak information on what is being done in the application/system background processes. If an application allows users to guess what the particulate next outcome will be by processing time variations, users will be able to adjust accordingly and change behavior. \n\n How to Test #1 \n Review the project documentation and use exploratory testing looking for application/system functionality that may be impacted by time. Such as execution time or actions that help users predict a future outcome or allow one to circumvent any part of the business logic or workflow. \n For example, not completing transactions in an expected time. \n\n How to Test #2 \n Develop and execute the mis-use cases ensuring that attackers can not gain an advantage based on any timing.",
"005": "Many of the problems that applications are solving require limits to the number of times a function can be used or action can be executed. Applications must be “smart enough” to not allow the user to exceed their limit on the use of these functions since in many cases each time the function is used the user may gain some type of benefit that must be accounted for to properly compensate the owner. \n\n Vulnerabilities related to testing for the function limits are application specific and misuse cases must be created that strive to exercise parts of the application/functions/ or actions more than the allowable number of times.\nAttackers may be able to circumvent the business logic and execute a function more times than “allowable” exploiting the application for personal gain. \n\n How to Test #1 \n Review the project documentation and use exploratory testing looking for functions or features in the application or system that should not be executed more that a single time or specified number of times during the business logic workflow. \n\n How to Test #2 \n For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times. \n For example, can a user navigate back and forth through the pages multiple times executing a function that should only execute once or can a user load and unload shopping carts allowing for additional discounts.",
"006": "Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application/system in a way that will allow them to circumvent (not follow) the designed/intended workflow. \n\n “A workflow consists of a sequence of connected steps where each step follows without delay or gap and ends just before the subsequent step may begin. Workflow may be seen as any abstraction of real work.” \n\n The application’s business logic must require that the user complete specific steps in the correct/specific order and if the workflow is terminated without correctly completing, all actions and spawned actions are “rolled back” or canceled. \n\n Generic Testing Method \n • Review the project documentation and use exploratory testing looking for methods to skip or go to steps in the application process in a different order from the designed/intended business logic flow. \n • For each method develop a misuse case and try to circumvent or perform an action that is “not acceptable” per the the business logic workflow. \n\n Testing Method 1 \n • Start a transaction going through the application past the points that triggers credits/points to the users account. \n • Cancel out of the transaction or reduce the final tender so that the point values should be decreased and check the points/credit system to ensure that the proper points/credits were recorded. \n\n Testing Method 2 \n • On a content management or bulletin board system enter and save valid initial text or values. \n • Then try to append, edit and remove data that would leave the existing data in an invalid state or with invalid values to ensure that the user is not allowed to save the incorrect information.\n Some “invalid” data or information may be specific words (profanity) or specific topics (such as political issues).",
"007": "The misuse and invalid use of of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Tests should be undertaken to determine whether there are application-layer defensive mechanisms in place to protect the application. \n\n The lack of active defenses allows an attacker to hunt for vulnerabilities without any recourse. The application’s owner will thus not know their application is under attack. \n\n This test is unusual in that the result can be drawn from all the other tests performed against the web application. \n While performing all the other tests, take note of measures that might indicate the application has in-built self-defense: \n • Changed responses \n • Blocked requests \n • Actions that log a user out or lock their account \n\n These may only be localised. Common localized (per function) defenses are: \n • Rejecting input containing certain characters \n • Locking out an account temporarily after a number of authentication failures \n\n Localized security controls are not sufficient. There are often no defenses against general mis-use such as: \n • Forced browsing \n • Bypassing presentation layer input validation\n • Multiple access control errors\n • Additional, duplicated or missing parameter names\n • Multiple input validation or business logic verification failures\n • Structured data (e.g. JSPN, XML) of an invalid format is received\n • Blatant cross-site scripting or SQL injection payloads are received\n • Utilising the application faster than would be possible\n • Change in continental geo-location of a user\n • Change of user agent \n • Accessing a multi-stage business process in the wrong order\n • Large number of, or high rate of use of, application-specific functionality \n\n Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? \n If not, the tester should report that the application appears to have no application-wide active defenses against misuse.",
"008": "Many application’s business processes allow for the upload and manipulation of data that is submitted via files. \n The risk in that by allowing users to upload files, attackers may submit an unexpected file type that that could be executed and adversely impact the application or system through attacks that may deface the web site, perform remote commands, browse the system files, browse the local resources, attack other servers, or exploit the local vulnerabilities, just to name a few. \n\n Vulnerabilities related to the upload of unexpected file types is unique in that the upload should quickly reject a file if it does not have a specific extension. Additionally, this is different from uploading malicious files in that in most cases an incorrect file may be detrimental to the saved data. \n\n Generic Testing Method \n • Review the project documentation and perform some exploratory testing looking for file types that should be “unsupported” by the application/system. \n • Try to upload these “unsupported” files an verify that it are properly rejected. \n • If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated. \n\n Specific Testing Method \n • Study the applications logical requirements \n • Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or html files containing script. \n • In the application navigate to the file submission or upload mechanism. \n • Submit the “not approved” file for upload and verify that they are properly prevented from uploading.",
"009": "Many application’s business processes allow for the upload of data/information. \n To reduce the risk we may only accept certain file extensions, but attackers are able to encapsulate malicious code into inert file types. \n\n Vulnerabilities related to the uploading of malicious files is unique in that these “malicious” files can easily be rejected through including business logic that will scan files during the upload process and reject those perceived as malicious.\nAdditionally, this is different from uploading unexpected files in that while the file type may be accepted the file may still be malicious to the system. \n\n General Testing Method \n • Review the project documentation and use exploratory testing looking at the application/system to identify what constitutes and “malicious” file in your environment. \n • Develop or acquire a known “malicious” file. \n • Try to upload the malicious file to the application/system and verify that it is correctly rejected. \n • If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated. \n\n Specific Testing Method 1 \n • Using the Metasploit payload generation functionality generates a shellcode as a Windows executable using the Metasploit “msfpayload” command. \n • Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected. \n\n Specific Testing Method 2 \n • Develop or create a file that should fail the application malware detection process. \n (there are many available on the Internet such as ducklin.htm or ducklin-html.htm) \n • Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected. \n\n Specific Testing Method 3 \n • Set up the intercepting proxy to capture the “valid” request for an accepted file. \n • Send an “invalid” request through with a valid/acceptable file extension and see if the request is accepted or properly rejected."
},
"client": {
"001": "DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. \n\nThe DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. \n A DOM-based XSS vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker. \n\n Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices. In comparison to other cross site scripting vulnerabilities, where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the user’s browser, a DOM-based XSS vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow. \n Due to their nature, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. \n\n An attacker may append #<script>alert(‘xss’)</script> to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. \n\n Testing for DOM-Based XSS vulnerabilities:\n Blackbox testing for DOM-Based XSS is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. \n Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option. \n The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with. User input comes in two main forms: \n • Input written to the page by the server in a way that does not allow direct XSS \n • Input obtained from client-side JavaScript objects \n\n Automated testing has only very limited success at identifying and validating DOM-based XSS as it usually identifies XSS by sending a specific payload and attempts to observe it in the server response. \n Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker.",
"002": "A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim’s browser. \n This vulnerability can have many consequences, like disclosure of a user’s session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior. \n\n Such vulnerability occurs when the application lacks of a proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occur during this content processing phase and consequently affect the victim. \n When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers.",
"003": "HTML injection is a type of injection issue that occurs when a\nuser is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. \nThis vulnerability can have many consequences, like disclosure\nof a user’s session cookies that could be used to impersonate the\nvictim, or, more generally, it can allow the attacker to modify the\npage content seen by the victims. \n\n This vulnerability occurs when the user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) the legit from the malicious parts and consequently will parse and execute all as legit in the victim context. \n\n There is a wide range of methods and attributes that could be used to render HTML content. If these methods are provided with an untrusted input, then there is an high risk of XSS. \n Malicious HTML code could be injected for example via innerHTML, that is used to render user inserted HTML code. An improper usage of this property, that means lack of sanitization from untrusted input and missing output encoding. \n If strings are not correctly sanitized the problem could lead to XSS based HTML injection.\n Another method could be document.write() \n\n When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers.",
"004": "Client Side URL Redirection, also known as Open Redirection, is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be malicious. \nThis kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page. \n\nThis vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker. \n\n By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.\n Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access. \n\n Testing for Client Side URL Redirect vulnerabilities: \nWhen testers have to manually check for this type of vulnerability they have to identify if there are client side redirections implemented in the client side code. \n These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. If the script does not perform any validation of the variable “redir”, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.",
"005": "A CSS Injection vulnerability involves the ability to inject arbitrary CSS code in the context of a trusted web site, and this will be rendered inside the victim’s browser. \nThe impact of such a vulnerability may vary on the basis of the supplied CSS payload: it could lead to Cross-Site Scripting in particular circumstances, to data exfiltration in the sense of extracting sensitive data or to UI modifications. \n\n Such a vulnerability occurs when the application allows to supply user-generated CSS or it is possible to somehow interfere with the legit stylesheets. \n Injecting code in the CSS context gives the attacker the possibility to execute JavaScript in certain conditions as well as extracting sensitive values through CSS selectors and functions able to generate HTTP requests. \n\n Specifically the attacker could target the victim by asking her to visit the following URLs: \n • www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current; (Opera [8,12]) \n • www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8) \n\n Much more interesting attack scenarios involve the possibility to extract data through the adoption of pure CSS rules. \nSuch attacks can be conducted through CSS selectors and leading for instance to grab anti-CSRF tokens. \n\n Testing for CSS Injection vulnerabilities: \n Manual testing needs to be conducted and the JavaScript code analyzed in order to understand whether the attackers can inject its own content in CSS context. In particular we should be interested in how the website returns CSS rules on the basis of the inputs.",
"006": "A ClientSide Resource Manipulation vulnerability is an input validation flaw that occurs when an application accepts an user controlled input which specifies the path of a resource (i.e. source of an iframe, js, applet). \nSpecifically, such a vulnerability consists in the ability to control the URLs which link to some resources present in a web page. \n The impact may vary on the basis of the type of\the element whose URL is controlled by the attacker, and it is usually adopted to conduct Cross-Site Scripting attacks. \n\n Such a vulnerability occurs when the application employs user\ncontrolled URLs for referencing external/internal resources. \n In these circumstances it is possible to interfere with the expected application’s behavior in the sense of making it load and render malicious objects. \n\n Testing for Client Side Resource Manipulation vulnerabilities:\nTo manually check for this type of vulnerability we have to identify whether the application employs inputs without correctly validating them; these are under the control of the user which could be able to specify the url of some resources. \n Since there are many resources that could be included into the application, client side scripts which handle the associated URLs should be investigated for potential issues. \n\n The following shows the possible injection points (sink) that should be checked: \n • Resource: Frame \n • Tag/Method: iframe \n • Sink: src \n\n • Resource: Link \n • Tag/Method: a \n • Sink: href\n\n • Resource: AJAX Request \n • Tag/Method: xhr.open(method, [url], true); \n • Sink: URL href\n\n • Resource: CSS \n • Tag/Method: link \n\n • Resource: Image \n • Tag/Method: img \n\n • Resource: Object \n • Tag/Method: object \n • Sink: src\n\n • Resource: Script \n • Tag/Method: script \n • Sink: data src",
"007": "Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform “cross-domain” requests using the XMLHttpRequest L2 API in a controlled manner. \n In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy. \n\n Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. \n In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers including: \n • Origin \n • Access-Control-Request-Method \n • Access-Control-Request-Headers \n • Access-Control-Allow-Origin \n • Access-Control-Allow-Credentials \n • Access-Control-Allow-Methods \n • Access-Control-Allow-Headers \n\n The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data.\n The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not. \n\n Check the HTTP headers in order to understand how CORS is used, in particular we should be very interested in the Origin header to learn which domains are allowed. \n Also, manual inspection of the JavaScript is needed to determine whether the code is vulnerable to code injection due to improper handling of user supplied input.",
"008": "ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. \n There are three\nversions of the ActionScript language. ActionScript 1.0 and ActionScript 2.0 are very similar with ActionScript 2.0 being an extension of ActionScript 1.0. ActionScript 3.0, introduced with Flash Player 9, is a rewrite of the language to support object orientated design. \n\n ActionScript, like every other language, has some implementation patterns which could lead to security issues.\n In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross-Site Scripting (XSS) could be present in flawed Flash applications.\n\n Decompilation \n Since SWF files are interpreted by a virtual machine embedded in the player itself, they can be potentially decompiled and analysed. The most known and free ActionScript 2.0 decompiler is flare. \n Decompilation helps testers because it allows for source code assisted, or white-box, testing of the Flash applications. HP’s free SWFScan tool can decompile both ActionScript 2.0 and ActionScript 3.0.\n\n Attacks and Flash Player Version Since May 2007, three new versions of Flash player were released by Adobe. Every new version restricts some of the attacks. \n\n Player Version: v9.0 r47/48 \n • asfunction: Yes \n • Externalinterface: Yes \n • GetURL: Yes \n • HTML Injection: Yes\n\n Player Version: v9.0 r115 \n • asfunction: No \n • Externalinterface: Yes \n • GetURL: Yes \n • HTML Injection: Yes\n\n Player Version: v9.0 r124 \n • asfunction: No \n • Externalinterface: Yes \n • GetURL: Yes \n • HTML Injection: Partially",
"009": "“Clickjacking” (which is a subset of the “UI redressing”) is a malicious technique that consists of deceiving a web user into interacting with something different to what the user believes they are interacting with. \n This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. \n\n A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. \n\n To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe. \n Once this is done, the attacker could induce the victim to interact with his fictitious web page.\nOnce the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page.\n\nThis type of attack is often designed to allow an attacker site to induce user’s actions on the target site even if anti-CSRF tokens are being used. . So it’s important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.\n\nWe have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. \nMethods to protect a web page from clickjacking can be divided in two macro-categories: \n • Client side protection: Frame Busting \n • Server side protection: X-Frame-Options \n\n Some frame busting techniques try to break frame by assigning a value to the “parent.location” attribute in the “counter-action” statement. Such actions are, for example: \n • self.parent.location = document.location \n • parent.location.href = self.location \n • parent.location = self.location",
"010": "Traditionally the HTTP protocol only allows one request/response per TCP connection. Asynchronous JavaScript and XML (AJAX) allows clients to send and receive data asynchronously to the server, however, AJAX requires the client to initiate the requests and wait for the server responses (half-duplex). \n\n HTML5 WebSockets allow the client/server to create a ‘full-duplex’ (two-way) communication channels, allowing the client and server to truly communicate asynchronously. WebSockets conduct their initial ‘upgrade’ handshake over HTTP and from then on all communication is carried out over TCP channels by use of frames. \n\n 1: Identify that the application is using WebSockets \n • Inspect the client-side source code for the ws:// or wss:// URI scheme\n • Use Browser Developer Tools to view the Network WebSocket communication \n • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab \n\n 2: Origin \n • Using a WebSocket client attempt to connect to the remote WebSocket server \n • If a connection is established the server may not be checking the origin header of the WebSocket handshake \n\n 3: Confidentiality and Integrity \n • Check that the WebSocket connection is using SSL to transport sensitive information (wss://) \n • Check the SSL Implementation for security issues s (Valid Certificate, BEAST, CRIME, RC4, etc). \n\n 4: Authentication \n • WebSockets do not handle authentication, normal black box authentication tests should be carried out \n\n 5: Authorization \n • WebSockets do not handle authorization, normal black-box authorization tests should be carried out \n\n 6: Input Sanitization \n • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab to replay and fuzz WebSocket request and responses",
"011": "Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. \n This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. \n It enables secure communication between multiple origins across iframes, tabs and windows. \n\n The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. \n\n There are some security concerns when using ‘*’ as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes: \n • data: The content of the incoming message \n • origin: The origin of the sender document \n • source: source window \n\nManual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. \nIn particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains.",
"012": "Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP). \n There are two objects, localStorage that is persistent and is intended to survive browser/system reboots and sessionStorage that is temporary and will only exists until the window or tab is closed. \n On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data stored in these two objects is kept in the client and never sent to the server. \n\n First of all, we need to check whether the Local Storage is used. This can be checked when using the Browser Tool and then go under Resources you will see ‘Local Storage’ and ‘Web Storage’. \n\n Next manual testing needs to be conducted in order to determine whether the website is storing sensitive data in the storage that represents a risk and will increase dramatically the impact of a information leak. \n Also check the code handling the Storage to determine if it is vulnerable to injection attacks, common issue when the code does not escape the input or output."
},
"no_info": "No information for given reference number found."
}
}
Reference in New Issue View Git Blame Copy Permalink