A web server in a shell script | Hacker News Reader

A web server in a shell script

debian-administration.org

49 pointschaosmachine27 comments

The author points this out but it probably bears repeating: this implementation is insecure as it exposes your entire filesystem to anyone who can connect to your port 80. Use with caution :)

The joy of VM's.

Yeah, you should totally deploy a separate virtual machine just to serve files from a toy Bash web server (irony).

He's right. The joy of VMs is that they let you play while throwing caution to the wind. Tone down the snarkiness.

Virtual machines are great for isolation and defense in depth, not as the only security measure. It's like believing that a firewall will magically solve all your network security problems.

For experiments relying on that is fine, but not for anything more serious.

Use with caution ... and chroot.

It includes a netcat-based webserver written in bash (that speaks CGI) as well as a Sinatra-like micro "framework" for shell (that also speaks CGI) that lets you do things like this:

    get "/DeanMartin.jpg" dean_handler
    function dean_handler () {
        header "Content-Type" "image/jpeg"
        cat "DeanMartin.jpg"
    }

Unfortunately I haven't figure out a way to get rid of that placeholder function name (e.x. "dean_handler" above). Ideas?

Bash is awesome.

This is one of my favorite bash scripts, it's an IRC bot in about 12 lines:

http://inamidst.com/code/shellbot

It's also pretty easy to add other commands & extend.

Unix is awesome.

I recently had lunch with a friend and I asked him about if he was planning new features their key/value store and I loved his answer: (paraphrased)

I'm a unix-guy. I want small bits of software that does one thing and does it really well.

His point was that software these days is rarely "finished". However in Unix so much of the software are small pieces. Each piece does one job and does it well. Then you can fit those pieces together in all sorts of configurations to do new and interesting things.

The unixlike nature of certain tools is what makes the Unix architecture more or less unique. Look at binutils and you'll find heaps of tools with amazing abilities like dd, cat and echo. For me, vim wins over emacs precisely because ultimately it's an editor. Emacs for me is a whole operating environment like Gnome (although I use both and appreciate that vim can be heavily extended).

Odd, I don't see any bash'isms in that; I think that script would run in Bourne shell. And in fact, it could be shorter and more efficient in bash. For example, it could probably use /dev/tcp instead of telnet. And it could pattern match with [[ $var == ]] or case instead of grep. And no need to use tail if you do appropriate redirections. I think. :)

Sorry bash is horrid. The extensions on on posix sh are completely brain dead except for associative arrays and a few other things. Most of the extensions in bash were already built into posix sh just with a different syntax. But then again posix sh is bad as well.

> you don't want the hassle of installing the full Apache package

    sudo apt-get install apache2
    sudo vim /usr/lib/cgi-bin/hello_world
    sudo chmod a+x $_

Not that much of a hassle.

Not to mention there are numerous minimalistic yet secure web servers available.

http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_s...

Install Apache on a VPS with 64MB or 128MB of RAM is a hassle.

Okay, replace the first line with:

    sudo apt-get install lighttpd

Don't blame Apache. Use the event mpm and don't use so many modules.

I prefer:

cd $WEB_DIR; python -m SimpleHTTPServer

twistd -n web --path .

for evented goodness.

This is a neat hack, but the title is a little misleading - most of the real work is handled by inetd, not the shell script.

Should every server re-implement inetd, though? Why not let that handle connections, daemontools/runit handle process supervision & logging, and focus on what you're actually trying to do?

You don't need OOP for reusability.

In the few cases where scalability matters, you can re-implement the relevant behavior, but that's a performance trade-off.

cat "$filename"

...

Oh dear. Ohdearohdearohdear.

Now all we need to do is make sure that the first character in $filename is "&" followed by some privilege escalation exploit and ...

(Am I missing something?)

Well the variable expansion is quoted, so afaik it could only be interpreted as a single argument to cat.

The double quote quoting, while allowing you to do e.g. rm "file with spaces" still expands $ and `. Compare:

echo none:`date`

echo double: "`date`"

echo single: '`date`'

But it doesn't expand recursively, so "$var" is safe to protect against special characters in var. That said, one should really read one's shell's documentation, because there be dragons.

Nothing about this is intended to be the least bit secure. It's a fun hack, nothing more.

Not saying there isn't an exploit here, but that's not it.

    % foo="& do_evil"
    % cat "$foo"
    cat: & do_evil: No such file or directory

Now if the request was for the path /../../../../../../etc/passwd ... that's a different story.

edit: and with the CGI stuff it might be possible to execute rm or something else dangerous/destructive.

Reply on news.ycombinator.com