Skip to main content

Home/ SoftwareEngineering/ Group items tagged OWASP

Rss Feed Group items tagged

kuni katsuya

Session Management Cheat Sheet - OWASP - 0 views

  • Session Management Cheat Sheet
  • should not be extremely descriptive nor offer unnecessary details
  • change the default session ID name of the web development framework to a generic name
  • ...50 more annotations...
  • length must be at least 128 bits (16 bytes)
  • Session ID Length
  • Session ID Name Fingerprinting
  • Session ID Properties
  • Session ID Entropy
  • must be unpredictable (random enough) to prevent guessing attacks
  • good PRNG (Pseudo Random Number Generator) must be used
  • must provide at least 64 bits of entropy
  • Session ID Content (or Value)
  • content (or value) must be meaningless
  • identifier on the client side
  • meaning and business or application logic associated to the session ID must be stored on the server side
  • session objects or in a session management database or repository
  • create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
  • Session Management Implementation
  • defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID
  • token expiration date and time
  • This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods
  • Transport Layer Security
  • use an encrypted HTTPS (SSL/TLS) connection for the entire web session
  • not only for the authentication
  • process where the user credentials are exchanged.
  • “Secure” cookie attribute
  • must be used to ensure the session ID is only exchanged through an encrypted channel
  • never switch a given session from HTTP to HTTPS, or viceversa
  • should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute)
  • should not offer public unencrypted contents and private encrypted contents from the same host
  • www.example.com over HTTP (unencrypted) for the public contents
  • secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist)
  • only has port TCP/80 open
  • only has port TCP/443 open
  • “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.
  • Secure Attribute
  • instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection
  • HttpOnly Attribute
  • instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object
  • Domain and Path Attributes
  • instructs web browsers to only send the cookie to the specified domain and all subdomains
  • “Domain” cookie attribute
  • “Path” cookie attribute
  • instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application
  • vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com
  • Expire and Max-Age Attributes
  • “Max-Age”
  • “Expires” attributes
  • it will be considered a
  • persistent cookie
  • and will be stored on disk by the web browser based until the expiration time
  • use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.
  • Session ID Life Cycle
kuni katsuya

Logging Cheat Sheet - OWASP - 0 views

  • Legal and other opt-ins
    • kuni katsuya
       
      terms & conditions acceptance, license transfers, etc
  • Data changes
    • kuni katsuya
       
      all changes to domain objects
  • Event attributes
  • ...35 more annotations...
  • Log date and time
  • Event date and time
  • Application identifier
    • kuni katsuya
       
      eg. service type
  • Application address
    • kuni katsuya
       
      eg. service instance
  • User identity
    • kuni katsuya
       
      ie. subject
  • Type of event
  • Severity of event
  • Description
    • kuni katsuya
       
      eg. event message text
  • Action
    • kuni katsuya
       
      eg. action performed on managed resource (eg. 'update' action on resource 'hotel')
  • original intended purpose of the request
  • Object
    • kuni katsuya
       
      eg. managed resource being accessed
  • affected component
  • Result status
    • kuni katsuya
       
      boolean was_successful
  • Reason
    • kuni katsuya
       
      include in event message text
  • Extended details
  • Data to exclude
  • Access tokens
  • Session identification values
  • Sensitive personal data
  • passwords
  • Database connection strings
  • Encryption keys
  • payment
  • Information a user has opted out of collection
  • Synchronize time across all servers and devices
  • Input validation failures
  • Which events to log
  • proportional to the information security risks
  • Always log:
  • Authentication successes and failures
  • Authorization failures
  • Session management failures
  • Application errors and system events
  • Application and related systems start-ups and shut-downs
  • Use of higher-risk functionality
kuni katsuya

Preventing SQL Injection in Java - OWASP - 0 views

  • Preventing SQL Injection in Java
  • inject (or execute) SQL commands within an application
  • Defense Strategy
  • ...19 more annotations...
  • To prevent SQL injection:
  • All queries should be
  • parametrized
  • All dynamic data
  • should be
  • explicitly bound to parametrized queries
  • String concatenation
  • should never be used
  • to create dynamic SQL
  • OWASP SQL Injection Prevention Cheat Sheet.
  • Parameterized Queries
  • Prepared Statements
  • automatically be escaped by the JDBC driver
  • userId = ?
  • PreparedStatement
  • setString
  • Dynamic Queries via String Concatenation
  • never construct SQL statements using string concatenation of unchecked input values
  • dynamic queries via the java.sql.Statement class leads to SQL Injection
kuni katsuya

SQL Injection Prevention Cheat Sheet - OWASP - 0 views

  • SQL Injection Prevention Cheat Sheet
  • it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.
  • create dynamic database queries that include user supplied input
  • ...19 more annotations...
  • a) stop writing dynamic queries
  • b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query
  • Primary Defenses:
  • Option #1: Use of Prepared Statements (Parameterized Queries)
  • Option #3: Escaping all User Supplied Input
  • Additional Defenses:
  • Enforce: Least Privilege
    • kuni katsuya
       
      least privilege should be *required*, included as a primary defense
  • Perform: White List Input Validation
  • Primary Defenses
  • Defense Option 1: Prepared Statements (Parameterized Queries)
  • attacker is not able to
  • change the intent
  • of a query, even if SQL commands are inserted by an attacker
  • allows the database to
  • distinguish
  • between
  • data,
  • code a
  • Defense Option 3: Escaping All User Supplied Input
kuni katsuya

Authentication Cheat Sheet - OWASP - 0 views

  • Authentication Cheat Sheet
  • Sessions should be
  • unique per user
  • ...26 more annotations...
  • computationally very difficult to predict
  • "strong" password policy
  • Secure Password Recovery Mechanism
  • Require re-authentication for Sensitive Features
  • Authentication and Error Messages
  • can be used for the purposes of user ID and password enumeration
  • Incorrectly implemented error messages
  • generic manner
  • respond with a generic error message regardless if the user ID or password was incorrect
  • give no indication to the status of an existing account
  • Authentication responses
  • Invalid user ID or password"
  • does not indicate if the user ID or password is the incorrect parameter
  • Transmit Passwords Only Over TLS
  • login page
  • all subsequent authenticated pages
  • must be exclusively accessed over TLS
  • unencrypted session ID
  • credentials
  • Implement Account Lockout
  • lock out an account if more than a preset number of unsuccessful login attempts are made
  • can produce a result that locks out entire blocks of application users accounts
    • kuni katsuya
       
      somewhat of a denial-of-service attack, since legitimate users can no longer access their accounts/services
  • sensible strategy
  • is to lockout accounts for a number of hours
  • Password lockout mechanisms have a logical weakness
  • Session Management General Guidelines
kuni katsuya

Forgot Password Cheat Sheet - OWASP - 0 views

  • Forgot Password Cheat Sheet
  • no industry standard for implementing a Forgot Password feature
  • Step 1) Gather Identity Data or Security Questions
  • ...12 more annotations...
  • asks the user for multiple pieces of hard data that should have been
  • previously collected
  • send the password reset information to some
  • out-of-band side-channel
  • such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3.
  • Step 2) Verify Security Questions
  • application verifies that each piece of data is correct for the given username
  • If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers.
  • Avoid sending the username as a parameter
  • Do not provide a drop-down list
  • server-side session
  • user's email account may have already been compromised
kuni katsuya

SQL Injection - OWASP - 0 views

  • SQL Injection
  • "injection" of a SQL query via the input data from the client to the application
  • exploit can
  • ...18 more annotations...
  • read sensitive data
  • modify database data
  • execute administration operations
  • SQL injection errors occur when:
  • Data enters a program from an
  • untrusted source
  • The data used to
  • dynamically construct a SQL query
  • consequences are:
  • Confidentiality:
  • sensitive data
  • Authentication
  • user names and passwords
  • Authorization
  • change this information
  • Integrity
  • read sensitive information
  • changes or even delete this information
kuni katsuya

Guide to SQL Injection - OWASP - 0 views

  • Least privilege connections
  • Always use accounts with the
  • minimum privilege necessary
    • kuni katsuya
       
      yet another reason why shared db logins (eg. etl_update) are a *BAD IDEA* ie. a set of apps using the same db login are effectively granted the 'highest common denominator' of db privileges, so have more access than they should (eg. update/delete privilege on tables unrelated to app)
  • ...9 more annotations...
  • for the application
  • Parameterized Queries with Bound Parameters
  • keep the
  • query
  • d data
  • separate through the use of placeholders known as "bound" parameters
  • how to Review Code for SQL Injection Vulnerabilities.
  • Guide to SQL Injection
  • "injection" of a SQL query via the input data from the client to the application
  •  
    "Least privilege connections"
1 - 15 of 15
Showing 20 items per page