Skip to content

Do not assume ModSecurityIntervention argument to transaction::intervention has been initialized/cleaned #3212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

eduar-hte
Copy link
Contributor

what

Minor changes to transaction::intervention to guarantee to caller that all members of the ModSecurityIntervention have been initialized if an intervention should be made and that the return value of the function is consistent with the state of the transaction.

why

The current version of Transaction::intervention assumes (and implicitly requires) that the ModSecurityIntervention argument has been initialized/cleaned before the call.

This is not necessarily expected because the parameter is used as an output parameter and it's not clear that any input is provided to the function.

Additionally, in order to make the API more robust, when the function returns that an intervention should be made, initialize all members in the structure to guarantee to the caller that all of them can be safely accessed and interpreted.

changes

  • Keep m_it->disruptive value and use it as return value to guarantee that the value is correct.
    • If m_it->disruptive is false and the it argument has not been initialized/cleaned, the function may incorrectly return a non-zero value.
  • When a disruptive intervention is being reported by the function, defensively initialize log & url fields to NULL if there's no such data to provide to the caller.
    • If the caller has not initialized/cleaned those fields in the it argument, after returning from transaction::intervention, the user can safely read the log & url fields (and call cleanup functions such as intervention::free or msc_intervention_cleanup -introduced in PR Add cleanup methods to complete C based ABI #3209).
  • Minor changes to improve & fix documentation of Transaction::intervention & msc_intervention.

…ention has been initialized/cleaned

- Keep m_it->disruptive value and use it as return value to guarantee
  that the value is correct.
  - If m_it->disruptive is false and the 'it' argument has not been
    initialized/cleaned, the function may incorrectly return a non-zero
    value.
- When a disruptive intervention is being reported by the function,
  defensively initialize log & url to NULL if there's no such data to
  provide to the caller.
  - If the caller has not initialized/cleaned those fields in the 'it'
    argument, after returning from transaction::intervention, the user
    can safely read the log & url fields and in all scenarios they'll
    have valid values.
- Initialize `log` temporary value on construction instead of doing
  default initialization and then calling `append`.
- Leverage `std::string_view` to replace `const std::string&` parameters
  in `utils::string::replaceAll` to avoid creating a `std::string`
  object (and associated allocation and copy) for the string literal`%d`
@marcstern marcstern added the 3.x Related to ModSecurity version 3.x label Aug 7, 2024
…on Unix builds

- This configuration flag was introduced in commit d47185d in the
  context of PR owasp-modsecurity#3207.
- Moved to the configure step's 'run' command in order to be shared
  across configurations.
- For the sake of reference, matrix.platform.configure should be used
  for configuration flags that are needed for a specific
  platform/architecture (which was the reason it was introduced in
  commit d9255d8, PR owasp-modsecurity#3144).
Copy link

sonarqubecloud bot commented Aug 8, 2024

Copy link
Member

@airween airween left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@airween airween merged commit 1d6e72e into owasp-modsecurity:v3/master Aug 8, 2024
49 checks passed
@airween
Copy link
Member

airween commented Aug 8, 2024

Thanks @eduar-hte!

@eduar-hte eduar-hte deleted the defensive-intervention branch August 8, 2024 15:48
airween added a commit to airween/ModSecurity that referenced this pull request Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.x Related to ModSecurity version 3.x
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants