Introduction
The Computational and Information Sciences and Technology Office (CISTO – Code 606) at the NASA
Goddard Space Flight Center (GSFC) provides a managed cloud environment using public cloud
services specifically designed for collaborative science and application development, to include the
hosting of public websites and web applications (webapps) within the Science Cloud (SC).
This document will cover the types of Websites/webapps permitted in the SC, website/webapp hosting
prerequisites, configuration recommendations, requirements for the use of JupyterHub environments
with user self-registration capabilities, and an attestation/signature.
Intake Questions for new Science Cloud WebApps
Type of Website (Custom WebAPI/WebApp, COTS WebApp, etc.)?
Desired Domain Name: xxx.sciencecloud.nasa.gov (As part of the migration, need to update the DNS records to reflect new location of Website in the Science Cloud)
URL registered with AWS Route53 or Azure?
MFA in use (interactive logins only) ?
Permitted Permitted WebApp Types in the Science Cloud
- Web
- Permissible websites or web applications include web services built using RESTful APIs with interactive content (custom or commercial WebApps)
- Static websites discouraged in favor of interactive applications in alignment with Agency Website Modernization Initiative
- Custom and/or commercial webapps For hybrid applications (e.g., a static site that redirects to something more interactive), contact Science Cloud team to discuss
- , as well as custom and/or commercial webapps.
- Static information-only websites are not authorized for deployment. All websites must comply with the Agency Website Modernization Initiative guidance. Users requesting static websites will be directed to approved alternative solutions.
...
Hosting Prerequisites
- 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
- All URLs must be registered URL
- with a valid DNS name (
- . IP addresses are not allowed)
- permitted. Encrypt
- All communications using HTTPS encryption with digital certificates.Port 443, port 80 not allowed
- must be encrypted using HTTPS on port 443 or alternative HTTPS ports (e.g., 8443). Port 80 is not permitted except to redirect to an
- HTTPS port
- .
- Multi-factor authentication (MFA) recommended
- must be used for all interactive logins, but username/password only authentication
- website logins. 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
- .
- All user input to web applications must be validated before processing. All user input displayed by web applications must be encoded before output.
- Websites must return generic error messages (e.g., 404 "page not found") for all errors, including non-existent pages and system failures. Error messages must not contain sensitive information such as system paths, database details, or stack traces that could assist an attacker.
- Do not use Host headers in server-side code or application logic. Instead, configure allowed hostnames in your server settings or hard-code legitimate domain names in your application.
- Prevent username enumeration in authentication flows. Login, registration, and password
reset functions must not reveal whether a username or email exists in the system.
- Never store passwords or sensitive information in cleartext within code repositories, wikis, or
other browsable services. Use secure secrets management solutions instead.
Configure web servers to block directory browsing and prevent access to application source code. Use industry-standard security hardening practices.
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
...