Skip to content

Conversation

@NicolasCARPi
Copy link

Hello,

Please kindly consider merging this changes. :)

  • completely change the sql injection paragraph as it would be silly to use anything other than prepared statements nowadays
  • introduce CSP in XSS part
  • Add a note for CSRF attacks with SameSite and same-origin
  • Add authentication part
  • talk about brute forcing a hash
  • talk about modern hashing functions for passwords

* completely change the sql injection paragraph as it would be silly to
  use anything other than prepared statements nowadays
* introduce CSP in XSS part
* Add a note for CSRF attacks with SameSite and same-origin
* Add authentication part
* talk about brute forcing a hash
* talk about modern hashing functions for passwords
@Oscar-Geare
Copy link
Contributor

Oscar-Geare commented Mar 18, 2024

completely change the sql injection paragraph as it would be silly to use anything other than prepared statements nowadays

Just because it would be silly, doesn't mean it's not common still. I still see many developers not using best practice in this area - but I mostly work in OT, where it's not uncommon for practices to be a little behind. A few years ago CrowdStrike put out a threat report where it was used as an access vector:
https://www.crowdstrike.com/blog/how-crowdstrike-stopped-an-sql-injection-campaign/

In the last year there were several CVEs released where CWE-89 was exploited.
https://www.cisa.gov/news-events/ics-advisories/icsa-24-074-12
https://nvd.nist.gov/vuln/detail/CVE-2024-24023
https://nvd.nist.gov/vuln/detail/CVE-2023-37197

Knowing the core technique and the basics on how to detect it is still very relevant, especially in environments where you might not control the application itself to put in stored procedures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants