...
Permitted WebApp Types in the Science Cloud
...
- 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
Self-Registration Requirements
- Some Science Cloud customers allow new users to “self-register” to gain access to JupyterHub environments
- Representative data items shall be collected at time of self-registration to allow for proper vetting, to include:
- Demographics (project name, user name, country)
- Affiliation (government funding, NASA affiliation, university status, etc.)
- Rationale (reason for request, justification)
- A NASA-approved warning banner shall be shown at the outset of all user registrations
...
- Risk-Based Decision Process: The team developed a Risk-Based Decision (RBD) framework allowing self-registration services with proper mitigating controls, turning security incidents into learning opportunities rather than blanket restrictions.
- Monitor CloudWatch events and GuardDuty notifications to determine if nefarious activities are occurring, such as:
- Communication with known cryptominer-affiliated URLs
- Presence of cryptominer binaries in the JupyterHub container
- Implement automated remediation processing to detect and stop all suspected incidents of nefarious/unapproved activity within provisioned JupyterHub environments, to include
- Disable affected JupyterHub user accounts
- Snapshot the Pod Physical Volume and Physical Volume Claim
- Terminate the pod and the active user session
- Email alert to the project sysadmin and security team
- Coordinate with Science Cloud’s security team to confirm stoppage of nefarious activity
...