Monthly Archives: September 2018

Notes From the book “Security Principles for PHP Applications”

Introduction: 

  • Do not treat application security as a “tack on” when building an application.
  • Best developers are lazy in a good way. They find ways to write efficient, reusable code.
  • Security is the job of an entire team.
  • Tools like Composer can be used to prototype applications. 
  • The extensions and libraries used in an application should be vetted for security, independently. 
  • JOSE stands for JSON Object Signing and Encryption standards. Not implementing it correctly can result in vulnerabilities added to the system.

Security First Mindset

  • Every line of code has to be written with the security first mindset. 
  • Users should have the permission to perform only the task that they need to and nothing more.
  • Security, data integrity and overall stability are as important as any other business requirement. 
  • The following tasks need to have the same level of precedence as user stories during planning:
    • Proper password management
    • Query parameterization
    • Server hardening
    • Request throttling
  • Here are a few things that compromise security so they should not be done:
    • Hardcoded password
    • HTTP Basic Authentication
    • non-SSL-protected server 
    • SQL queries via string interpolation
  • Threat modeling should be used in development.
  • Regulations like PCI and HIPAA won’t necessarily apply on apps that are social media extensions.

ASR1: Injection

  • Injection attacks occur when user input is erroneously trusted.
  • List of things that can be done with an injection attack:
    • Use a server for DDoS attack
    • Send spam or phishing emails
    • Use server as a prox or host
  • A framework should not allow the ability to inject non-alphanumeric characters into a SQL statement.
  • Users should be protected against certain characters like apostrophes that can be part of a name or non-Latin characters.
  • Do not use unparameterized SQL queries.
  • In SQL, values should be sanitized with SQL-specific mechanisms.
  • Timestamps should be passed through functions that ensure that they are positive values. 
  • One way to protect against the malicious use of passthru() is to use a whitelist of filenames that can be used. 
  • In many situations readfile can be used instead of passthru() to mitigate the risks caused when an unescaped shell argument is passed.
  • Two general rules of thumb for working with data: 
    • Sanitize all incoming data before using it
    • Escape all outgoing data

Advertisements