You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

 

Permitted WebApp Types in the Science Cloud

  • 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.


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 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

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.net.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