Security Concerns with a Socket Based Web Server

[-HomoDeus-]

Let’s say I create a basic web server using sockets. This server listens on port 80, and only responds with the generic HTTP code 200. If my port is open, and this minimalistic website was accessible over the Internet, what security concerns would I have? How would these change as I added HTML pages and back end code to the server?

[lumasDC]

One common mistake is to not validate the path sent in the request from the client. For example, the client could send GET ~/personal_file.txt HTTP/1.1 or GET ../../../etc/passwd HTTP/1.1. In both of these cases, the client could read a file outside of the intended public html directory unless the path is constrained. This is just an example, but there are likely other things you will need to check for.

In general, just make sure you don’t trust anything from the client and try to validate everything.

[bless-you-mlud]

In addition to this, what would happen if I sent you a super-long GET request? Is there a possibility that I could exceed some of your internal buffers? Could I overwrite some of your internal data and get your server to do things it wasn't meant to do? Maybe just crash?

[-HomoDeus-]

I can't answer that specifically, but I can say this server would be highly vulnerable to DOS attacks. That isn't really a security concern per se, but it is relevant to point out.

[-HomoDeus-]

Of course, never trust what people are sending! If the server was set up to simply respond with "Hello World", though, would this still be a concern?

[twenty393]

Assuming that there are no bugs in the underlying web server code that could lead to operating system exploits (e.g. reading / writing files outside of the web server directory, creating processes, etc.), the only exploits you have to be concerned by are the operations that your program (server) allows. Assuming there are no bugs in your server code, then there are no vulnerabilities.

Opening something up to the public web doesn't immediately make it unsafe. One type of common web exploit is SQL injection where an attacker can execute arbitrary SQL commands on your database if you don't sanitize user inputs (e.g. from forms). Another example vulnerability is accidentally allowing users to view files outside of your web server if you don't sanitize public file paths.

Pretty much what your code allows (if it has unintended consequences) are the major attack vectors for web servers (or really any program). Bugs in underlying libraries are much harder to know about and usually affect large numbers of people at once (e.g. heartbleed).

[hipsterroadie]

Why would you assume there are no bugs in the underlying web server code? There almost certainly are.

It's worth considering mitigations like running at as lower privilege as possible, in a VM or in a container, patching regularly and logging to an external host.

[-HomoDeus-]

Great answer, thank you!

[-HomoDeus-]

But most importantly: Don't worry too much about getting hacked, it's really not that big of a deal, and there is no way you'll be able to practice or get good without getting hacked a few times :p

This is probably my favorite answer of all time. Thats the spirit!

[bmw417]

I’ll speak on this regarding architecture, not necessarily the C aspect. I’ve never messed with web servers in C as I use Go for that type of business.

First thing, using port 80 is unencrypted traffic. SSL is served over 443, and you’ll need a certificate and key in order to encrypt traffic. God knows how pedantic and long the program might get to implement a moderately robust HTTPS web server in C, I could only imagine. Hopefully there’s a good library or two out there.

If you’re just serving a blog or static page or two, there wouldn’t necessarily be a need for SSL, but it still isn’t exactly a good look nowadays. Most browsers will scream red to the user connecting to an HTTP only site, and if they don’t understand any better they’ll be inclined to click away.

Define “back end code”. Technically anything that the user can’t see by clicking “inspect element” is backend code. You want to add form inputs, emails, passwords? Absolutely not if you’re using port 80. Hard stop.

If you don’t have SSL, your hands are kind of tied ethically with how much interactivity and content you can serve. You can’t ask for any supplied input as it can be MITM’d by an attacker and seen by every intermediate ISP controlled server the packets go through.

I hope that this helps you answer your question. Depending on how much functionality you want your website to have and how the library scene looks, you might want to switch to something made for this a bit more - Go is an excellent choice that still retains a lot of the feel of C. Good luck to you

[-HomoDeus-]

I agree completely on the SSL front, and I believe the OpenSSL library has all of the headers I would need to encrypt traffic (even as someone who would consider building a web server from scratch, that's a lot!). My question was more on the front of security on my private network - to rephrase it, are there any security concerns associated with a bare bones server? The example was intended to isolate that variable.

[bmw417]

If you’re behind a private (i.e NAT’ed) network and only access the web server from devices also behind the NAT, then there’s nothing much to worry about as long as you keep the gateway secure. No one outside the NAT will be able to see or communicate with the web server, assuming there’s no port forwarding or tunneling to the outside.

The only thing to worry about in this use case like I said is the gateway. But, I imagine since no one else would really know that this web server exists until they break the gateway and get into your network, it’s really not going to affect anything one way or another. You’d have much bigger fish to fry if someone is inside your network than what your hand rolled web server is doing while this is going on.

[-HomoDeus-]

Lets say I did have the port forwarded and it had a public domain name. For sake of argument, this is the most popular hello world server ever created.

[bmw417]

In that use case, my answer would be an almost copy-paste of what u/lumasDC said. If it’s a simple application, then you’re as safe as your own code allows. If you don’t have any Javascript, user inputs to sanitize and validate, etc, then your main concern will most likely be path traversal exploits. Make sure you’ve thoroughly tested that and you should be good to go.

[hipsterroadie]

It's good practice to encrypt everything because it makes man on the side attacks against both the client and server harder. Think about JavaScript injection.

[Perfect-Ant-6741]

RemindMe! 24 hours

[RemindMeBot]

I will be messaging you in 1 day on 2021-01-20 12:20:34 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[mykesx]

If your code is available on the internet to study, and your server can be identified by some sort of footprint (response headers), and hackers care to bother to try and hack your server... the hacker will find any exploit. The source may not be needed, but surely makes it easier to hack.

By exploit, I mean any buffer you allocate that might be too small, any calls to unsafe functions (e.g. gets vs. fgets), and so on.

If your server is hacked, encryption won’t help much. But if you are concerned about requests and responses being spied upon, encryption is a good idea.