Show HN: Nigit – Expose Shell Scripts as HTTP API

19 points by morgenkaffee 9 years ago | 6 comments
  • wink 9 years ago
    While it's nice and handy I'd be cautious to let that run anywhere else than localhost.

    To sanitize/whitelist this kind of input as in json -> go -> shell.. I'm giving up, I'm too paranoid to even think about making this safe :)

    • throwaway7767 9 years ago
      A coworker once set up a bash-based shell wrapper to provide customers with restricted access to the monitoring system. The monitoring system was written as CGI programs in C, and the shell script was there to sanitize input arguments, and that the hosts/tests being viewed matched the customers regex pattern (say, ".*\.customer\.tld").

      The next day, I showed him how I could break out of that protection by sending a request with a parameter like "host=x.customerb.tld\0.customera.tld" (with a NULL byte in between).

      We did a few more rounds of whack-a-mole until I finally managed to convince him this was a fundamentally bad idea.

      • morgenkaffee 9 years ago
        Completely agree!

        One approach is to run it in a Docker container and access it from your other micro services and never expose it to the public. This is still handy because you can isolate that old program and act as if it is an API to your other micro services.

      • 9 years ago
        • dozzie 9 years ago
          How did we end with everything being "API" and nothing being "service" any longer?
          • wanda 9 years ago
            Acronyms are trendier. and fewer bytes of you're performance-obsessed.
            • leesalminen 9 years ago
              > and fewer bytes of you're performance-obsessed

              Not if you include the requisite conversations about why acronyms are cool.