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

  1. Type of Website (Custom WebAPI/WebApp, COTS WebApp, etc.)?

  2. 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)

  3. URL registered with AWS Route53 or Azure?

  4. MFA in use (interactive logins only) ?

Permitted WebApp Types in the Science Cloud

  • Permissible websites or web applications include web services built using RESTful APIs, 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

  • All URLs must be registered with a valid DNS name. IP addresses are not permitted.
  • All communications must be encrypted using HTTPS on port 443 or alternative HTTPS ports (e.g., 8443). Port 80 is not permitted except to redirect to HTTPS.
  • Multi-factor authentication (MFA) must be used for all website logins. Username/Password-only authentication is not permitted.
  • 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


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


Auto-Remediation Recommendations for WebApps with Self-Registration

  • 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


Questions

How do you register an xxx.sciencecloud.nasa.gov subdomain?

Contact support@sciencecloud.nasa.gov and the team will guide you through the processes, which includes reviewing the web hosting guidelines and answering questions such as: What kind of code do you have? What is the intention of the code? What domain do you want? A change control process is then initiated in which the request is reviewed by the operations team, security, and Science Cloud management.

 

We currently have a webapp/site from our time using SMCE. Do we need to redo the process of approval to continue using our webapp/site on Science Cloud?

No, if you have already gone through the approval process on SMCE, you do not need to redo the process with Science Cloud. No new documentation is required unless you are changing your app (e.g., making changes to make it more accessible, like taking it out from behind the NASA firewall). However, in time we would like to transition all SMCE domain names to Science Cloud.


Contact Information

To move forward with your WebApp or to learn more, contact the Science Cloud team at support@sciencecloud.nasa.gov.

  • No labels