Secure coding education

  • Jim Manico
  • @manicode

  • [ ] make a process checklist for security

  • VPC is not enough to protect microservices.

  • WAF (Web App Firewall)
  • don't hack without legal written permission.
  • being compliant doesn't equal being secure.
  • Step-skipping-attack
  • IE6 is super insecure, secure softwaree can't be built for this browser
  • security salmon
  • ASVS - Application Security Verification Standard
  • NIST National Institute of Standards and Technology

Clickjacking / UI Redress

  • gmail example

SQL injection

  • block any http request that looks like SQL injection
  • or attack. '1'='1'
  • usually the first user in the user_table is the root user
  • timing attack
  • SQL Map
  • anytime a sql statement is build by concat strings, it has risk
  • even valid data can cause injection eg '
  • you can't parametrize column name and tablename in some languages. you have to validate those names.


  • every single webpage by default should be treated as auth-required page instead of only validating the pages that should be logged in.
  • do re-authentication eg in Amazon when the user is going to checkout the shopping cart
  • re-authentication to prevent session hijacking and CSRF: cross-site scripting attacks,
  • re-auth before being able to reset password or email.. since email is used to change password
  • SMS for MFA is easy to get around
  • login/pwd is not enough
  • TOTP - easily phishable
  • FIDO standard - the safest since it checks to the hardware. eg. Yubikey
  • push notifications to auth
  • The german banks have very effective security policies.
  • absolute timeout vs idle timeout
  • in login/pwd auth failure don't specify what failed
  • send all usernames over HTTPS
  • time attacks to see which usernames are good or bad
  • Bcrypt - to hash passwords
  • don't use usernames as public like twitter do. Use your login username and have another that's the display name
  • if you lock out an account for brute-forcing, don't notify them on the website, but send them an email.
  • do phishing campaign to your own company to detect any weaknesses and to educate.
  • for single-sign on use OpenId-Connect
  • use mutual TLS from server to server

Session Fixation

  • create new session ID at login to protect

Password storing

Best practices

  • don't limit the chars or length of passwords


  • hashing is easy decifered with the proper equipment. , 6billion passwords per second
  • encryption - superadmins can decrypt passwords.. so that's the weakness
  • salted hash - they will throw an assault of trillion times to the superadmin


  • PBKDF2
  • scrypt
  • salt is meant to prevent dedupe attacks, not brute force attacks
  • a work factor how much work has to be applied to decrypt, that translates into time.
  • RSA)


  • delegation framework
  • OAuth2.0 is token-based
  • it's like a valet key - like valet parking key. Has it's limitations for safety reasons. so you don't need to giveout your user/pwd.
  • [not out of the box]federation: to give access from one party to another like with a single-sign-on (eg. GE to Salesforce). Federation gives full power, instead of just a subset of features.
  • like when an app requests permission to use your twitter account to read your tweets.
  • be very careful with tokens. and use them only for delegation.
  • refreshtoken pattern recommended only for social media. refresh_token is like Kerberos ticket ``
  • tokens can be very dangerous, see OAuth2 and road to hell
  • tokens are sent to and from the browser by GET params.



Oauth2.0 Grant

  • the implicit grant is super unsecure


  • Strict Contextual Escaping & HTML Sanitization - stops XSS
  • Content Security Policy
  • for CSRF


  • no Content Security Policy support
  • bad escaping

results matching ""

    No results matching ""