new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

OWASP Cheat Sheets · all subjects

application_security/testing

15 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Run static analysis security testing with ESLint or JSHint

Use Static Analysis Security Testing (SAST) tools like ESLint or JSHint to identify security patterns without executing code. These linting tools are essential for dynamic, loosely-typed JavaScript. Periodically review linting rules, audit findings, and add custom rules for dangerous patterns.

REST security testing challenges

Security testing of REST services faces unique challenges: inspecting the application does not reveal the full attack surface as URLs and parameters are often activated dynamically and not visible in page links; parameters are non-standard making them difficult to identify; the large number of parameters in JSON structures increases fuzzing time significantly; and custom authentication mechanisms require reverse engineering, making standard tools ineffective for session tracking.

REST penetration testing methodology: attack surface determination

To determine the attack surface of a REST service, obtain formal service descriptions (WSDL 2.0 or WADL if available), developer guides, or application source code and configuration files. Clear-box testing is preferable to ensure fuller coverage of the attack surface. Collect full requests using a proxy tool (not just URLs) as REST services use more than just GET parameters.

REST attack surface analysis: detecting non-standard parameters

When analyzing collected REST requests to identify non-standard parameters, look for abnormal HTTP headers that may be header-based parameters. Examine URL segments for repeating patterns such as dates, numbers, or ID-like strings indicating URL-embedded parameters (e.g., http://server/srv/2013-10-21/use.php). Identify structured parameter values in JSON or XML format. Check if URL elements lack extensions, especially if the application technology normally uses extensions or previous segments have extensions (e.g., http://server/svc/Grid.asmx/GetRelatedListItems). Identify highly varying single URL segments that may be parameters rather than physical directories (e.g., if http://server/src/XXXX/page repeats with hundreds of values for XXXX).

REST parameter verification technique using invalid values

To verify whether a suspected URL segment is a path element or a parameter, set the value to an expected invalid value. A path element will return a 404 message from the web server, while an invalid parameter value will return an application-level message since the value is legal at the web server level.

REST fuzzing optimization through collected request analysis

After identifying potential parameters to fuzz, analyze collected values for each parameter to determine valid versus invalid values so fuzzing can focus on marginal invalid values (e.g., sending 0 for values found to be always positive integers). Identify sequences allowing fuzzing beyond the range presumably allocated to the current user. Always emulate the authentication mechanism used by the REST service when performing fuzzing.

Brakeman Rails security scanner

Use brakeman, an open source static code analysis tool for Rails applications, to identify potential security issues. It can find easily exposed issues but does not necessarily produce comprehensive findings. Review brakeman documentation for warning types.

Bearer code security scanner for Ruby and JavaScript

Use bearer, an open source code security and privacy analysis tool for Ruby and JavaScript/TypeScript, to identify OWASP Top 10 potential issues. It provides configuration options and integrates into CI/CD pipelines.

Dawnscanner Rails static analyzer

Dawnscanner is a static analyzer for security issues in Rails, Sinatra, and Padrino applications. Version 1.6.6 includes more than 235 Ruby-specific CVE security checks.

Gauntlt Rails security testing tool

Gauntlt is a security testing tool built on cucumber using gherkin syntax to define attack files for Rails testing.

Risk analysis and threat modeling prerequisites for architecture

Before designing cloud architecture, enterprises must perform risk assessments, threat modeling activities, and attack surface assessments to identify: what threats an application might face, the likelihood of those threats actualizing as attacks, the attack surface with which those attacks could be targeted, and the business impact of losing data or functionality due to said attack. This is necessary to properly scope the security of an architecture.

Secret logging fidelity verification in exercises

Ensure fidelity of logging information during purple team exercises by verifying: what should have been logged, what was actually logged, and whether adequate alerts are in place.

Security Automation in SSC

Automation of security tasks such as scanning, monitoring, and testing is critical for complex SSCs. Tools supporting automation include SAST, DAST, SCA, and container image scanners. Automation is not a replacement for manual reviews by skilled professionals but provides scale and consistency. The automation tools themselves must be maintained, secured, and configured correctly. Tools are one component of an overall SSCS program and cannot identify all vulnerabilities.

SAST usage for OSS component analysis

SAST tools can be used not only for detecting potential security issues in custom-developed code but also on OSS components within the SSC. SAST tools can produce both false positives and false negatives, so results must undergo manual verification and should not be interpreted as a comprehensive view of project security. With understood limitations, SAST scans can prove useful when analyzing internally developed or OSS code.

Binary composition analysis for final builds

After the build process finishes, binary composition analysis should be performed on the final result. This can help detect exposed secrets, detect unauthorized components or content, and verify integrity. This task should be performed by both suppliers and consumers.

Give your agent this brain