#security
37 posts

Avoiding vulnerabilities in software development

Impose proper input validation. Beware of information exposure. Ensure proper authentication to assign privileges.
Read more

Avoiding vulnerabilities in software development

Impose proper input validation:
1. Apply the zero trust principle and assume all input is unsafe until proven otherwise. Whitelist validated environmental variables, queries, files, databases and API calls.
2. Realize that attackers may be able to access hidden form fields.
3. Validate input for content, as well as length. Evaluate type, syntax, and conformance to logic (semantic sense).
4. Perform both client-side and server-side checks.
5. Validate inputs again after any data combination or conversion.

Beware of information exposure:
1. Frame your error messages so that they do not give away the full path of a file or program, or expose a user in the database.
2. Contain sensitive information to areas with explicit trust boundaries. Use access controls to secure and restrict connections between ‘safe’ areas and endpoints.
3. Restrict sensitive information from URLs or communication headers. Obscure path names and API keys.  

Ensure proper authentication to assign privileges:
1. Make sure temporary privilege escalations are easily reversed, and soon.
2. Assign privileges through whitelisting, starting with a universal base of least privilege, rather than restricting them through blacklisting.
3. Never allow a lower privilege level to affect a higher privileged user.
4. Restrict log-in attempts and impose session limits.
5. Separate higher-level privileges into different roles to limit ‘power users’.
6. Apply multi-factor authentication.

Full post here, 6 mins read

The API security maturity model

The API Security Maturity Model is a corollary to the Richardson Maturity Model associated with RESTful API design, describing four levels of REST compliance. It describes cumulative levels of security, complexity, and efficiency.
Read more

The API security maturity model

  • The API Security Maturity Model is a corollary to the Richardson Maturity Model associated with RESTful API design, describing four levels of REST compliance. It describes cumulative levels of security, complexity, and efficiency.
  • Level 0 uses API keys and basic authentication, which is fundamentally insecure as it assumes whoever has the key is the rightful owner of it. There is basically no separate authorization process.
  • Level 1 uses token-based authentication but still conflates authentication and authorization, or produces quasi-authentication where the token acts as an ID card but is vulnerable to malicious intent as you assume the possession of the token is itself guarantee against mal-intent.
  • Level 2 uses token-based authorization, where authentication tokens allow entry but access and privileges are regulated by a system such as OAuth, with permissions designed to match a token’s lifespan and purpose or be set so that tokens age out of use; however, these systems are designed to be authoritative so you need to ask whether you can trust the system the token comes from, and also consider the reliability of data in transit, as tokens can collect more data and alter it as they pass through the system, so you need to monitor who adds data and what sort.
  • Level 3 uses claims for a centralized trust system, which gathers context and verifies information about the subject rather than simply trusting the caller, API gateway or token issuer; to achieve this, you need an asserting party you trust to verify the context and subject attributes for each claim with signed tokens (using private and public keys).

Full post here, 10 mins read

Severe truth about serverless security and ways to mitigate major risks

Cloud providers may secure your databases, operating systems, virtual machines, the network, and other cloud components, but you must still protect your application layer against cyber attacks.
Read more

Severe truth about serverless security and ways to mitigate major risks

  • Cloud providers may secure your databases, operating systems, virtual machines, the network, and other cloud components, but you must still protect your application layer (code, business logic, data and cloud service configurations) against cyber attacks.
  • Traditional web application firewalls only protect functions called through an API gateway. So, apply perimeter security to each function, incorporate whitelist validation, monitor updates to functions, and add runtime defense solutions.
  • Be wary of third-party dependencies. Derive components from reliable official sources via secure links. For Node.js applications, use package locks or NPM shrinkwrap to restrict updates to code until you review them. Identify and fix vulnerabilities with automated dependency scanners.
  • Ensure all credentials that invoke third-party services or cross-account integrations are temporary or encrypted and use a cryptographic key management solution. Set strict constraints on input/output messages passing through the API gateway.
  • Address the downside of autoscaling, DoW (denial of wallet) attacks: set budget limits with alarms, limit the number of API requests in a given time window, use DDOS protection tools, and try to make API gateways internal and private.

Full post here, 7 mins read

Best practices for user account, authorization, and password management

Impose a cryptographically strong irreversible hash of the password, salting it with a value unique to that specific login credential.
Read more

Best practices for user account, authorization, and password management

  • Impose a cryptographically strong irreversible hash of the password, salting it with a value unique to that specific login credential.
  • Separate user identity from the user account, designing your user management system for low coupling and high cohesion between different parts of a user’s profile. Allow users to change usernames and link multiple identities to a single user account.
  • Keep username rules reasonable, remain case-insensitive and avoid restricting length and character set. Also, allow as long and complex a password as a user wants (your hashing will condense it anyway).
  • Consciously decide on thresholds for session length and re-verify authentication for security in case of certain events like password resets, critical profile changes, logins from new devices or too many devices, or a sensitive action with perhaps financial implications. Offer users the option for increased security when alerting for such events and ensure even unsaved activity prior to authentication are preserved.
  • Build a secure authorization system, with password reset and not retrieval, detailed activity logging, rate-limiting of login attempts, locking out users after several unsuccessful attempts, and 2-factor re-authentication for new devices or long-idle accounts.

Full post here, 9 mins read

Ruby on Rails: Ensuring security is covered in your application

Use strong parameters to accept data being sent to you from a request, supplying whitelisted values to throw an error if incorrect data comes in.
Read more

Ruby on Rails: Ensuring security is covered in your application

  • Set up authentication to verify user access. You can use devise, which uses Bcrypt, to make it difficult for hackers to compute a password. It can also help recover passwords, register and track sign-ins, lock records, etc.
  • Use strong parameters to accept data being sent to you from a request, supplying whitelisted values to throw an error if incorrect data comes in.
  • Add slugs to URLs to identify records in an easy-to-read form without releasing the id of the record.
  • Protect sensitive data, especially logins and payment pages, by enforcing https through the config file and averting cross-site scripting (XSS) attacks.
  • Check for active record exceptions and create an exception concern to sit above the application controller to guard against specific exceptions.

Full post here, 3 mins read