Grapevine is a simple web application that allows users to add public Twitter and Facebook feeds. The application reads the posts from these feeds and makes a list of upcoming events for the user to see. The user can also specify a list of interests that will be matched with tags on events so listed events are more relevant. The app may support the ability for group users to add an organization and add custom events for other users to follow and see. The app may also support the ability for users to edit event information or delete events in their private view.

The following diagram represents Grapevine:

• PII
  • Real name
  • Email Address
• User data
  • Username
  • Password
  • Groups they follow
  • Interests
  • User roles
• Authentication Tokens
• Events
  • Facebook
  • Twitter
  • Group-created

• Admin - Someone who has the capability to change or delete user accounts and posts without incurring the fee
  • Can create, read, update, and delete all PII, user data, and events
• User - Someone who has registered and has a public profile - can add feeds and can access event information
  • Can create, read, and update their own PII and user data
  • Can requests event feed sources
  • Can access event information

Role	Operation	Assets
		PII	User Data	Authentication Tokens	Events
User	Create	Always	Always	Never	Sometimes
	Read	Sometimes	Sometimes	Sometimes	Always
	Update	Sometimes	Sometimes	Never	Sometimes
	Delete	Never	Never	Never	Never
Admin	Create	Always	Always	Never	Always
	Read	Always	Always	Sometimes	Always
	Update	Always	Always	Never	Always
	Delete	Always	Always	Never	Always

• Authentication Tokens
• TODO - HTTPS

This application is unlikely to be attacked, but attackers will probably be script kiddies or online hackers that want to inject or spoof event data. It is unlikely that the website will be attacked by organized crime attackers or be the target of governmental forces.

1. An attacker can Create, Read, Update, or Delete PII
2. An attacker can Create, Read, Update, or Delete User Data
3. An attacker can Create, Read, Update, or Delete Authentication Tokens
4. An attacker can Create, Read, Update, or Delete Events
5. An attacker can gain unauthorized access to the filesystem contents
6. An attacker can gain unauthorized code execution on the machine

1. An attacker can deny service from the website to its users

• If the application is using a SQL database, an attacker can use SQL injection to Create, Read, Update, or Delete data. Alternatively, an attacker can cause unintended behavior by crafted XML or JSON (A1)
  • Use parameterized queries or prepared statements whenever using SQL queries, even if it is not obvious that it takes user input
  • Ensure that deserializers can safely handle untrusted data
  • Sanitize data if a deserializer cannot safely handle untrusted data
• The application has broken authentication or session management (A2)
  • Ensure that session tokens are checked and verified at every sensitive endpoint of the site
  • Ensure that session tokens are generated with sufficient entropy so they aren't predictable and aren't reused
  • Ensure that session tokens expire within a reasonable length of time
  • Ensure proper length and complexity requirements on passwords, and make sure the passwords are salted and hashed using a secure algorithm
• The application allows for Cross Site Scripting (A3)
  • Ensure that any user input that may be reflected (either from a form or in a query parameter) is escaped or checked against a whitelist of acceptable characters
  • Utilize Content Security Policy (CSP)
• The application allows insecure direct object references (i.e. look up information by account number) (A4)
  • Use indirect object references and perform a 1-1 mapping on the application side
  • If direct references must be used, verify the user making the request has authorization to access the resource
• The security is misconfigured on the server or in the application (A5)
  • Ensure the operating system and all components of the application (libraries, databases) are updated fully
  • Ensure unnecessary features (admin consoles, accounts, directory listing, etc.) are disabled.
  • Change default passwords
  • Return generic error messages when there's an issue (Don't allow a user to see a full stack trace)
  • Ensure all security features of frameworks used are enabled
• The application exposes sensitive data to attackers (A6)
  • Ensure that the application uses TLS and strong cipher suites only
  • Make sure cookies are set to Secure and if possible HttpOnly
  • Use HSTS and Certificate Pinning if possible
  • Use proper HTTP Security Headers
  • Don't store passwords using a reversible encryption algorithm - only use strong hashes (like bcrypt and scrypt)
  • For things that must be stored using reversible encryption, like credit card information, use strong encryption algorithms like AES and use secure key storage
  • When serializing data to send to a client, ensure that the serialized data doesn't contain any data not directly needed at the time of the response
  • Ensure that all debugging features are turned off at release time
• An attacker can access application functionality they don't have access to (A7)
  • Make sure that all authenticated endpoints verify authentication for all functionality. For example, use middleware to ensure requests made to handlers for administrative pages or user pages have the requisit level required
• An attacker can execute a Cross Site Request Forgery (CSRF) attack (A8)
  • Use CSRF synchronizer token (preferably at the double submit cookies and the encrypted token patterns)
  • Check the referrer header to make sure it makes sense (this is difficult to spoof)
  • Ask the user to perform a challenge when making requests that are secure or sensitive in nature (i.e. re-entering passwords, entering a captcha, etc)
• The application may use components that have known vulnerabilities (A9)
  • Prior to using any third party components, verify that the current versions don't show up on the CVE list or the National Vulnerability Database
  • Make sure that all libraries and applications used on the server are updated and appropriate access controls are used to prevent more access than absolutely required
• The application does not validate user input used for redirects (A10)
  • Don't allow user input to be used directly in a redirect - redirect based on a mapping of options to acceptable targets
  • If user input must be used for a redirect, validate using a URL parsing library against a whitelist of acceptable URLs
• An attacker can exhaust resources of an application
  • Ensure that rate limiting is implemented to a reasonable level
  • Use performant cryptography and hashing methods that are still cryptographically secure
  • Write code that fails prior to doing expensive computations on data (though if the data is sensitive, take care not to introduce vulnerabilities to timing attacks)
  • Require authentication before doing expensive computations, and limit users to a quota.
  • Ensure sufficient entropy is generated, and if entropy is perpentually low, consider using the built in hardware RNG or haveged
• An attacker can learn information from poorly designed or written cryptography
  • DON'T WRITE YOUR OWN ENCRYPTION OR SECURE HASHING ALGORITHM
  • There is almost never a reason to design encryption or hashing algorithms
  • If secure encryption or hashing libraries don't exist for the language, seriously consider using another language
  • Use secure algorithms like SHA-256 for hashing, bcrypt/scrypt for hashing with a salt, AES for encryption, HMAC for authenticating messages
  • Ensure items that need to be cryptographically secure use secure random number generators with sufficient entropy
• An attacker can gain access to filesystem contents or run unauthorized code (RCE)
  • Ensure that if the application accesses filesystem contents, sufficient controls and restrictions are in place to prevent arbitrary file reads
  • Don't construct language statements based on unverified user input

Even though the potential security risk is low due to the nature of the application, care must still be taken in the development of it to ensure security issues are kept to a minimum. Throughout the coding process, the threat model will be kept updated as new assets are added, vulnerabilities anticipated, or countermeasures implemented.