java-html-sanitizer

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

If this is your project, please show your badge status on your project page! The badge status looks like this: Badge level for project 2602 is passing Here is how to embed it:

These are the Passing level criteria. You can also view the Silver or Gold level criteria.

        

 Basics 13/13

  • Identification

    Takes third-party HTML and produces HTML that is safe to embed in your web application. Fast and easy to configure.

    What programming language(s) are used to implement the project?
  • Basic project website content


    The project website MUST succinctly describe what the software does (what problem does it solve?). [description_good]

    https://github.com/OWASP/java-html-sanitizer/blob/master/README.md says

    "A fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS."



    The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software. [interact]

    https://github.com/OWASP/java-html-sanitizer/blob/master/README.md says

    "Subscribe to the mailing list to be notified of known Vulnerabilities. If you wish to report a vulnerability, please see AttackReviewGroundRules."



    La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) (URL required) [contribution]

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.



    The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements]
  • FLOSS license

    What license(s) is the project released under?



    The software produced by the project MUST be released as FLOSS. [floss_license]

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    It is SUGGESTED that any required license(s) for the software produced by the project be approved by the Open Source Initiative (OSI). [floss_license_osi]

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    The project MUST post the license(s) of its results in a standard location in their source repository. (URL required) [license_location]

    Non-trivial license location file in repository: https://github.com/OWASP/java-html-sanitizer/blob/master/COPYING.


  • Documentation


    The project MUST provide basic documentation for the software produced by the project. [documentation_basics]

    Some documentation basics file contents found.



    The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. [documentation_interface]

    https://github.com/OWASP/java-html-sanitizer/blob/master/docs/getting_started.md provides "getting started" documentation that points to generated JavaDoc which explain the core APIs in detail. For example:

    https://static.javadoc.io/com.googlecode.owasp-java-html-sanitizer/owasp-java-html-sanitizer/20181114.1/org/owasp/html/HtmlPolicyBuilder.html

    The project includes example policies which users have successfully tailored to their needs.


  • Other


    The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. [sites_https]

    Given only https: URLs.

    Github hosts the markdown documentation via https. javadoc.io hosts documentation generated from source via https. Download information is available from maven central via https.



    The project MUST have one or more mechanisms for discussion (including proposed changes and issues) that are searchable, allow messages and topics to be addressed by URL, enable new people to participate in some of the discussions, and do not require client-side installation of proprietary software. [discussion]

    GitHub supports discussions on issues and pull requests.



    The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. [english]

    All documentation is available in English.

    Documentation for filing issues and reporting security issues is available in English: https://github.com/OWASP/java-html-sanitizer/blob/master/.github/ISSUE_TEMPLATE.md



    The project MUST be maintained. [maintained]


(Advanced) What other users have additional rights to edit this badge entry? Currently: []



  • Repositorio público para el control de versiones de código fuente


    El proyecto DEBE tener un repositorio público para el control de versiones de código fuente que sea legible públicamente y tenga URL. [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.



    El repositorio fuente del proyecto DEBE rastrear qué cambios se realizaron, quién realizó los cambios y cuándo se realizaron los cambios. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. [repo_interim]

    It is SUGGESTED that common distributed version control software be used (e.g., git) for the project's source repository. [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


  • Numeración única de versión


    The project results MUST have a unique version identifier for each release intended to be used by users. [version_unique]

    https://github.com/OWASP/java-html-sanitizer/blob/master/RELEASE-checklist.sh explains how version numbers are obtained.

    They are monotonic but unfortunately not semver :(



    It is SUGGESTED that the Semantic Versioning (SemVer) or Calendar Versioning (CalVer) version numbering format be used for releases. It is SUGGESTED that those who use CalVer include a micro level value. [version_semver]

    The project started using YYYY.MM.DD.SERIAL fairly early on. Unfortunately, changing that might adversely affect existing clients.



    It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. [version_tags]
  • Notas de lanzamiento


    The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes). Projects whose results are not intended for reuse in multiple locations (such as the software for a single website or service) AND employ continuous delivery MAY select "N/A". (URL required) [release_notes]

    The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A. [release_notes_vulns]
  • Bug-reporting process


    The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL required) [report_process]

    The maintainer monitors the Github issue tracker. https://github.com/OWASP/java-html-sanitizer/issues



    The project SHOULD use an issue tracker for tracking individual issues. [report_tracker]

    The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. [report_responses]

    https://github.com/owasp/java-html-sanitizer/issues?utf8=%E2%9C%93&q=is%3Aissue+created%3A%3E%3D2018-04-20+ indicates that of 18 issues raised in the last 12 months (relative to 20 Apr 2019) all were responded to.



    The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive). [enhancement_responses]

    https://github.com/owasp/java-html-sanitizer/issues?utf8=%E2%9C%93&q=is%3Aissue+created%3A%3E%3D2018-04-20+ shows 4 enhancement requests in the last 12 months all of which were responded to.



    El proyecto DEBE tener un archivo públicamente disponible para informes y respuestas para búsquedas posteriores. (URL required) [report_archive]

    All non-security issues available at https://github.com/OWASP/java-html-sanitizer/issues?utf8=%E2%9C%93&q=is%3Aissue

    Security reports found to be actionable summarized at https://github.com/OWASP/java-html-sanitizer/blob/master/docs/vulnerabilities.md

    Non-actionable security reports are stored in https://bugcrowd.com/owaspjavasanitizer but are not public.


  • Proceso de informe de vulnerabilidad


    The project MUST publish the process for reporting vulnerabilities on the project site. (URL required) [vulnerability_report_process]

    Both the README and the issue report template point to https://github.com/OWASP/java-html-sanitizer/blob/master/docs/attack_review_ground_rules.md which provides some background before pointing reporters to https://bugcrowd.com/owaspjavasanitizer



    If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required) [vulnerability_report_private]

    OWASP uses https://bugcrowd.com/owaspjavasanitizer to track reporting and bounties for this project.



    The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. [vulnerability_report_response]

    I believe I have never taken longer than 72 hours to respond to a report and provide a patch for the actionable ones.


  • Working build system


    Si el software generado por el proyecto requiere ser construido para su uso, el proyecto DEBE proporcionar un sistema de compilación que pueda satisfactoriamente reconstruir automáticamente el software a partir del código fuente. [build]

    Se SUGIERE que se utilicen herramientas comunes para construir el software. [build_common_tools]

    Non-trivial build file in repository: https://github.com/OWASP/java-html-sanitizer/blob/master/pom.xml.

    Maven is pretty standard for Java libraries.



    El proyecto DEBERÍA ser construible usando solo herramientas FLOSS. [build_floss_tools]

    Maven is open-source. Ancillary tools like bash and GPG are open-source. There are open-source Java compilers that are compatible with the source code and the .travis.yml file uses checks that the project builds on several openjdk versions: https://github.com/OWASP/java-html-sanitizer/blob/ea101ceb2d68a990f87e5ec88337e27569be7515/.travis.yml#L5-L6


  • Automated test suite


    The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). [test]

    https://github.com/OWASP/java-html-sanitizer/tree/master/src/test/java/org/owasp/html has most of the test files.

    It includes unit tests which due to the nature of the project are heavily tilted towards negative tests, and a number of hand-crafted fuzzers to suss out crashing issues: https://github.com/OWASP/java-html-sanitizer/blob/master/src/test/java/org/owasp/html/HtmlSanitizerFuzzerTest.java



    Un conjunto de pruebas DEBERÍA ser invocable de forma estándar para ese lenguaje. [test_invocation]

    mvn verify is idiomatic for this kind of project and works as expected.



    It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. [test_most]

    mvn test site generates a jacoco coverage report at target/site/jacoco/index.html. Below is the summary:

    Element Missed Instructions Cov. Missed Branches Cov. Missed Cxty Missed Lines Missed Methods Missed Classes Total 1,853 of 33,163 94% 431 of 2,404 82% 398 1,710 337 4,120 64 462 0 85

    As part of this process, added build machinery to capture historical rates at https://coveralls.io/github/OWASP/java-html-sanitizer?branch=master



    It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). [test_continuous_integration]
  • New functionality testing


    The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. [test_policy]

    This has been the policy but has not been documented.



    The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. [tests_are_added]

    https://gist.github.com/mikesamuel/8b16a0de692b77171cf38825b2f4f601 shows that 71.42% of the commits in the last 20 that touch source files also touch test files. Some of the ones that do not are comment only changes but I have not attempted to filter those out.



    It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. [tests_documented_added]
  • Banderas de advertencia


    The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. [warnings]

    El proyecto DEBE abordar las advertencias. [warnings_fixed]

    All IDE warnings and issues are addressed.

    mvn compile site generates a report that has 1 low priority issue and 2 medium priority issues. The reasons for all these are documented. 2 are related to supporting multiple versions of Java & Guava. 1 is a dead store that is considered less bad than the maintenance hazard of not keeping the variably nominally consistent.



    It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. [warnings_strict]

    mvn compile site generates an analysis report that includes

    FindBugs Version is 3.0.1 Threshold is low Effort is max

    https://github.com/OWASP/java-html-sanitizer/blob/95d89afa17d704b3dc044b76909579a2af2a5aae/parent/pom.xml#L76-L85


  • Conocimiento de desarrollo seguro


    The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.) [know_secure_design]

    I am the primary developer, am a security engineering professional, and am published in my field.

    http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.306.6704 http://webblaze.cs.berkeley.edu/csas.html



    At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them. [know_common_errors]

    The primary author has worked on similar systems used in high profile projects like Gmail.


  • Use buenas prácticas criptográficas

    Note that some software does not need to use cryptographic mechanisms. If your project produces software that (1) includes, activates, or enables encryption functionality, and (2) might be released from the United States (US) to outside the US or to a non-US-citizen, you may be legally required to take a few extra steps. Typically this just involves sending an email. For more information, see the encryption section of Understanding Open Source Technology & US Export Controls.

    The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used). [crypto_published]

    No cryptography is used. This is a string to string transform.



    Si el software producido por el proyecto es una aplicación o una librería, y su propósito principal no es implementar criptografía, entonces DEBE SOLAMENTE invocar un software específicamente diseñado para implementar funciones criptográficas; NO DEBERÍA volver a implementar el suyo. [crypto_call]

    No cryptography is used. This is a string to string transform.



    All functionality in the software produced by the project that depends on cryptography MUST be implementable using FLOSS. [crypto_floss]

    No cryptography is used. This is a string to string transform.



    The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled. [crypto_keylength]

    No cryptography is used therefore there it is technically true that "there is no key length in this project that is shorter than a key length used by any other project ever."



    The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are inappropriate to the context, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol. [crypto_working]

    No cryptography is used. This is a string to string transform.



    The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH). [crypto_weaknesses]

    No cryptography is used. This is a string to string transform.

    Full disclosure: This project depends on common tools like git which use SHA-1 internally and which cannot currently be configured to do otherwise.



    The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. [crypto_pfs]

    No cryptography is used. This is a string to string transform.



    If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). See also OWASP Password Storage Cheat Sheet. [crypto_password_storage]

    This project does that.

    It is possible that a very odd configuration might allow an <input type=password> to make it from input through to output but those would neither be "stored" nor "for authentication of external users."



    The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure. [crypto_random]

    No secrets are generated and the use of PRNGs is restricted to test code (see fuzzers). I believe the static analysis done on mvn verify would detect uses of java.util.Random instead of java.util.SecureRandom outside test code but have not tested.


  • Entrega garantizada contra ataques de hombre en el medio (MITM)


    The project MUST use a delivery mechanism that counters MITM attacks. Using https or ssh+scp is acceptable. [delivery_mitm]

    This sends no network messages. It is a string to string transform.



    A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and used without checking for a cryptographic signature. [delivery_unsigned]

    This project does no cryptography. It is a string to string transform.


  • Vulnerabilidades públicamente conocidas corregidas


    There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. [vulnerabilities_fixed_60_days]

    The bugcrowd queue is clear and has been. I get a few reports a year and respond promptly.



    Projects SHOULD fix all critical vulnerabilities rapidly after they are reported. [vulnerabilities_critical_fixed]

    I believe I have done this and intend to continue.


  • Otros problemas de seguridad


    The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access. [no_leaked_credentials]

    This library accepts no credentials, sends no network messages, nor IPC, and provides hooks to enable logging but does not log any inputs itself.


  • Análisis estático de código


    At least one static code analysis tool (beyond compiler warnings and "safe" language modes) MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language. [static_analysis]

    mvn compile site generates target/site/findbugs.html which is run and checked as part of the release checklist.



    It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment. [static_analysis_common_vulnerabilities]

    Error prone provides these bug patterns https://errorprone.info/bugpatterns The maven file does not turn any off that are on by default, so patterns like https://errorprone.info/bugpattern/InsecureCryptoUsage would surface uses of deprecated crypto APIs.



    All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. [static_analysis_fixed]

    The IDE configured checker produces no warnings or errors.

    mvn compile site generates a report that has 1 low priority issue and 2 medium priority issues. The reasons for all these are documented. 2 are related to supporting multiple versions of Java & Guava. 1 is a dead store that is considered less bad than the maintenance hazard of not keeping the variably nominally consistent.



    It is SUGGESTED that static source code analysis occur on every commit or at least daily. [static_analysis_often]

    It runs every commit as part of the mvn verify calls ( https://github.com/OWASP/java-html-sanitizer/blob/ea101ceb2d68a990f87e5ec88337e27569be7515/scripts/build_for_travis.sh#L13-L17 ) that is kicked off by .travis.yml.


  • Dynamic code analysis


    It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release. [dynamic_analysis]

    The code was developed alongside fuzzers crafted for this particular product.

    See *FuzzerTest.java in https://github.com/OWASP/java-html-sanitizer/tree/master/src/test/java/org/owasp/html

    Thanks for the pointer. I may reach out to OSS-Fuzz for additional assurance.



    It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). [dynamic_analysis_unsafe]

    Code is in Java and includes no methods marked with keyword native. The only runtime dependency is Guava so the native method surface is small.



    It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds. [dynamic_analysis_enable_assertions]

    For example, the serializer is security sensitive so includes assertions about its output. See https://github.com/OWASP/java-html-sanitizer/blob/ea101ceb2d68a990f87e5ec88337e27569be7515/src/main/java/org/owasp/html/HtmlStreamRenderer.java#L289 which is a runtime assertion that checks that the output will parse to the same structure.



    All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. [dynamic_analysis_fixed]

    This is a library and it does not phone home with telemetry but we follow up on issues that include reports of runtime errors due to assertion failures.



This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Mike Samuel and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Mike Samuel.
Entry created on 2019-03-14 18:15:48 UTC, last updated on 2019-04-20 19:43:45 UTC. Last achieved passing badge on 2019-04-20 19:43:45 UTC.

Back