feat: enhance descriptions

[wurstbrot]

Enhancements based on questions/comments from @vbakke.

[wurstbrot]

Wanted to show how to document evidence. I think this is not the right place for it and causes confusions

[vbakke]

Maybe 'Usage' page is the place to say some more about evidence and how to document this?

[vbakke]

I fixed a couple of spelling mistakes, and rephrased a couple of sentences in PR #15

[vbakke]

I see that you removed this. I think it is worth leaving is. It is an easy, and important, first stepping stone. We just need to make the text more similar to Treatment of defects with severity high or higher (44f2c8a9-4aaa-4c72-942d-63f78b89f385).

BTW, Fix based on accessibility (0c10a7f7-f78f-49f2-943d-19fdef248fed) depends on this.

[vbakke]

Maybe 'Usage' page is the place to say some more about evidence and how to document this?

[vbakke]

I still think a description should be added to explain what Contextual encoding actually is.

A search for Application Hardening "Contextualized Encoding" mainly refers back to DSOMM.

[wurstbrot]

It learned the the term Contextualized Encoding from @philippederyck .
What do you think about Output Encoding?

TSS Web describes it like this:

Every access to backend systems such as databases MUST be parameterized1, e.g. via prepared statements, OR mappers (e.g. Hibernate) when an API for this matter does exist.

[philippederyck]

I have 0 context, but it sounds like you're trying to mash two concepts together.

Parametrization is an effective way to separate code and data (e.g., SQL statement and parameters, HTML template and variables, ...), which is crucial to be able to apply proper defenses.

Context-sensitive output encoding is for example used when inserting data into HTML pages, to avoid an HTML parser down the line from seeing data as code. The context-sensitive part relates to the fact that encoding is different based on which context the data ends up in (e.g., html element/html attribute/url/javascript/css block/css attribute).

For example, with SQLi, parametrization allows the construction of the statement's syntax before adding any data, which prevents injection (e.g., with a prepared statement or similar approach). For XSS, context-sensitive output encoding can be applied manually at output time, or the use of parametrization allows frameworks like Angular/React/Vue to apply this automatically.

Hope this helps.

[vbakke]

Ah, then I think I get it. Thanks @philippederyck :)👍

In terms of activities in DSOMM, I think we need to keep proper SQL parameterization separate from proper HTML escaping, @wurstbrot. Apart from that deep down it is all about swapping characters around, I don't see that these have much in common. These two activities are normally performed by different people (i.e. back-end and front-end developers, respectively).

I haven't found any other activities mentioning hibernate/entity framework (or other SQL libraries).

I suggest we split the Contextualized encoding into:

• SQL Injection Defense
• HTML Sanitization and Encoding

(or some other and better wording : )

@wurstbrot: Have you split activities before? Do you make any special considerations to backwards compatibilities, uuids etc?

[vbakke]

Suggestion?

SQL Injection Defense

Description

If a system concatenates strings (some of which are based on user input) to build SQL queries, an attacker can manipulate the query to do other unintentional SQL commands as well.

Risk

Systems vulnerable to SQL injections may lead to data breaches, loss of data, unauthorized alteration of data, or complete database compromise or downtime.

Measure

• Use parametrized queries (or prepared statements)
• Use stored procedures
• Use ORM (Object-Relational Mapping) tools that automatically handle input sanitization

Implementation Guide

• https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

HTML Sanitization and Encoding:

Description:

If input from any user is displayed on the web page, care must be taken in case this input contains HTML or other executable code. For example if user input is inserted in innerHTML, the code will be executed by the
browser.

Risk

Without properly sanitizing user input when rendering HTML, an attacker may gain control over the user session.

Malicious user input can execute arbitrary actions like stealing session cookies, redirecting users to malicious sites, or defacing the page. This can result in XSS attacks, loss of user trust, and potential data leaks.

Measure

• Use modern frameworks such as React/Angular/Vue/Svelte. The default method
  renders data in a safe way.
• If you are using bare bone JavaScript, use innerText/textContent
  instead of innerHTML when displaying data. Sanitize input data to
  only contain allowed characters.
• Implement content security policies (CSP) to restrict the types of content
  that can be loaded and executed.

Implementation Guide

• https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html

[wurstbrot]

Thank you for the great input @philippederyck .

@vbakke ,

I think we are on the right track. We do not want a specific attacks in the title. Otherwise we need to add NoSqli also. Both will have the same abstract measure.

Activitiy: SQL Injection Defense -> Parametrization
Samples: SQLi, NoSQLi, path traversal, command injection, email header injection.

Activity HTML Sanitization and Encoding -> Output-sensitive encoding
"Use modern frameworks such as React/Angular/Vue/Svelte. The default method renders data in a safe way." -> "Use modern secure by default ui frameworks such as React/Angular/Vue/Svelte. The default method renders data in a safe way."

[vbakke]

Is there a url missing for the [False Positive Handling] ?