...
- Any new public-facing websites/webapps must be vetted and approved by Science Cloud’s admin team prior to being brought online
- Recommended domain structure: https://xxx.sciencecloud.nasa.gov
- If that is not possible (e.g., in the case of existing applications), the Science Cloud team can work with you
- Any new domain hosted within the Science Cloud must be registered using AWS Route53 or Azure DNS services
- Change Control Board approval process involving operations, security, and management
...
Configuration Guidelines
General Requirements
- Use registered URL with valid DNS name (IP addresses not allowed)
- Encrypt communications using HTTPS encryption with digital certificates.
- Port 443, port 80 not allowed except to redirect to an HTTPS port
- Multi-factor authentication (MFA) recommended for all interactive logins, but username/password only authentication is not permitted due to security risks
- Dependent on type of data/app being hosted
- Websites must return a generic error page (404, “page not found”) when a user navigates to a non-existent page to avoid exposing code details that could give hackers conduits into your application
- Never store passwords or other sensitive information in cleartext within Wiki, GitHub, or any other services that include browsable web pages
- Prohibit access to browsable web directories or application code unless designed for that purpose
Input Validation
- All user input used in web applications must be properly validated, and any user input output by web applications must be properly encoded
- Examples include:
Request URLs
DOM properties
Client hostnames
Uploads (file contents as well as metadata)
Uploaded filenames
LocalStorage / SessionStorage / IndexedDB
3rd party data (API responses)
WebSocket messages
Environment variables
Query string parameters
POST data
Cookie (and other header) values
- Anything that anyone or anything outside of your system can influence (even indirectly) should be validated for the context the input will be used in
Username/Password Reset and Access
- All publicly accessible data, including operational items such as error or warning messages, should not reveal information that can be used by an attacker
- Username enumeration shall be restricted as discovery of this information can be used to identify valid usernames and gain unauthorized access
- Stay away from overly helpful “forgot/reset password” links that have different responses depending on whether the supplied username exists
- A better alternative is to determine if a matching username or email address exists and then email a reset link
- Pay attention to any request that has anything to do with usernames, where you get a different response depending on whether the username is valid or not
Host Headers
- It’s useful to be able to programmatically ask ‘what’s the hostname I’m currently running from’ (e.g., constructing URLs dynamically)
- But host: header is a client-supplied value and is easily changed; depending on the web server configuration its possible to supply an arbitrary value without breaking expected webapp function
- It’s possible to rely on host: header value indirectly without realizing it
- When in doubt, if you’re programmatically determining your server name, ensure that the value doesn’t come from the host: header or any other user-influenceable value
User Input
- Design your application so that user input is inherently less dangerous: so that you’re not using it in a way that it is being passed to a database or an underlying operating system
- For dynamic SQL queries, use parameterized queries instead of concatenating strings
- Instead of putting user input in a command string, use a library that serves the same function as the command being called
- Avoid these common pitfalls that allow for SQL Injection or Command Injection attacks
...