[Delphi] Building my own webserver.

Okay, situation. I happen to have Borland Delphi 2005 and want to use the Indu Internet components to build my own webserver. No IIS, no Apache. My compiled executable will just be the webserver. It's service would be pretty simple, for internal usage on a small network. One PC will be the webserver and other PC's can access it through a web interface.

It's purpose... Well, whatever I like to experiment with. The server would generate pages dynamically yet it won't support PHP, ASP or whatever other scripting language. I don't want them either. If I want to modify the site served by this server, all I would have to do is modify the sourcecode. It is for personal experiments anyway.

My question however is security-relaed, though. I will run this server on my computer and thus it is exposed to the whole Internet. Although my firewall will keep all ports closed, I do want to access this server from the outside and thus hackers could access this server too. I can make this server pretend it's IIS or Apache to obfuscate it's real face, but security through obfuscation isn't a good solution...
Of course, I can add password-protected pages and use SSL to keep things secure and perhaps some other security measures and this isn't really what I am worried about. I'm not too afraid of people browsing that site anyway since it won't contain any sensitive information. Just whatever I like to experiment with. :D

However, I am more worried about hackers gaining access to my system through other means. What kind of other vulnerabilities should I be aware of? Is there any security risk in these Indy components or in Delphi that could be used by a hacker to gain access to my system? Bur example, through some buffer overflow or whatever?

It would be more secure than IIS or Apache since the hackers will be less familiar with this kind of webserver, so they would have more troubles with it. But do they still have some other ways to break in once I open this single port to my system? A port that is controlled by my own application?

I don't think so but want to be sure. So that's why I ask this. :)

if its a custom system, you will not be attacked by script kiddies, worms or bots but I would recommend useing an obscure port instead of 80 or 8080.

as for labels, give it something unique that dosnt betray its nature. Like "Katja systems ltd." not "my leeto dorito web server", that should throw off most of the more curious hackers, ultimatly though you have to concider, you are not a big target, who is going to go out of their way to attack you? why?

as I said, a custom build system is hard to penetrate, cover the basics and you should be fine. (../ symbols, buffers, invalid requests etc), use regular expressions and discard everything that is suspicious.

Tangent: You can support PHP by pipeing the php source to the php binary and taking the off stream back to the client.

Yes, I know that I won't be a big target but the thing is, I will access this webserver from anywhere. So if I visit an Internet cafe or use the computers at my university, I have to be aware that someone might be looking over my shoulder and read the URL that I am visiting.

Those who might try to attack my server could be fellow students from my school and whomever uses my computer next in the Internet cafe. I have to be aware of keyloggers and insecure connections when I'm using those computers, though. And if I happen to make some extremely useful tool that can be used as a webserver solution and start selling it or just giving it away for free, I would like it to be as secure as possible.

About extending the system, that won't be too difficult. I am going to make it modular, making a main executable that serves as webserver and all kinds of modules that could be used to extend the functionality of this server. This way I could add PHP support if I want to, or support for whatever else I like. But the main module should be secure.

But what is most important for me is knowing if there would be any vulnerabilities in such a setup. So when a hacker knows the link of my server and knows it's custom-written, I would like to know which other vulnerabilities I have to be aware of.

Erm, custom built systems aren't all that hard to bust normally, you just have less opportunity to find some canned hack via google. If you have basic software testing/penetration testing skills you will have plenty of opportunity to misuse the system in question. And hiding the web server on another port isn't exactly going to do a whole lot, especially if you suggest 8080 (which is the most common port people use as an alternative to 80 in my experience). It only makes it worse to have the system on a university network where bored computer nerds will have more opportunity and interest in scanning your system to see what they can do.

The security for your web server software all depends on the design of your system and how much power you give it while it executes.

You'll want to check on items like the following:
1) Ensure it can run as a low privilege user (so definitely not root...the less power the better).
2) Check to make sure it has the appropriate level of auditing.
3) Do your due dillegence when it comes to testing the software. Verify that it has the appropriate levels of input validation, error handling, performance levels, and handles failure gracefully (things go very bad when your application crashes and dumps it's namespace...revealing everything that it had in memory including user names, passwords, ports, etc).
4) Double check the areas where the software has the ability to write to the filesystem. Does it really need the access you've given it?
5) Double check the areas where the software can call api's, libraries, or external executables.
6) Verify that the host operating system has been sufficiently hardened.
7) Double check your firewall settings and logging, since this is your experimental system lots of logging everywhere could be a good thing so you can see the outcome of your own testing as well as what everyone else is doing to your work.
8) You may want to think about running your web server behind a squid reverse proxy. Doing this could increase your logging capability as well as ensure that people cannot start tossing funny things (or at least limit what they can toss) at your webserver. Oreilly has excellent books on setting this up.
9) Consider using a host intrusion detection system....this could give you a little more info if someone actually does something to the box.

Katja, If you want secure (even if custom built is incredibly secure mainly due to it not being widely known) use rexexp where ever you can, and use a zero tollerance policy on anything that dosnt match a standard statement, this will basicaly eliminate 90% of all possible attacks, if not more.

Alot of vulns are found where the programer has tried to do something "smart", for examples IE's ability to recognize that a file names something.jpg acctualy contains VBScript, the clever thing they did was then tell IE to execute it as VBScript instead of simply saying "This is not an image", and thus, image exploits were born.

flagrant use of 404 and 500 will help you alot, or even just blackhole the bastards.

As for your proposed attack vector, it seems a tad bit on the side of paranoia.

Well, a bit of paranoia has never been harmful in my opinion. :D
This year I will be using on a school project that will include the use of a webserver. Normally, we would have to choose between Apache on Linux or IIS on Windows. IT is my intention to use my own webserver for this, with the added note that this way my server would be more secure than any of the other solutions. It's that simple.
Vulnerabilities in the webpages could of course provide an attacker access to parts that I don't want them to access. But I want to be sure there are a minimum of vulnerabilities in my webserver.
The reason for this solution is pretty simple too. The whole thing must be easy to distribute to another system too. Well, what is easier to distribute than a single executable and perhaps a few DLL's that can actually use XCopy to distribute it all? :D

I wouldn't really worry about getting cracked. I doubt anyone would find you.

If you haven't gone to far with it already, I would suggest not using Indy for this type of application. Anybody can get the source for the package. That was just a thought. Good Luck with your project!

I'd recommend you use Apache and CGI though:

1) No need to learn how to parse/exchange in HTTP/1.1 (do you understand GET & POST requests, cookie requests, HTTP/file headers, character sets, keep-alive, server-browser handshakes, to name a few...?) Browsers are picky, and if you upset them your page will not load. The server on the other hand has to deal with all of the quirks of each browser that accesses it.
2) Do you understand how to spawn child processes and perform basic thread-management such as preventing race-conditions between threads? Otherwise you've just crippled support with some major browsers (both firefox and ie, among others) and created problems for yourself.
3) Do you really want to recompile your entire custom web server *just* to add in a single new feature? What if it breaks something and the whole thing doesn't work? When you get something that big, it becomes a major hastle.


CGI (Common Gateway Interface) was made with these things in mind. See if your language has CGI libraries. I've made some CGI applications in Plain C and it worked alright. PERL was a bit better. But PHP (Hypertext Preparser) is the motherlode & awesome.

CGI will do what you want.

You can write your own application to do whatever you want, and it'll be compatible with all browsers. You can implement your own security at either the Apache level or at your CGI application. With Apache set up properly the only thing being exposed would be your own custom application. So brush up on your coding skills, otherwise there will be some possible exploits.

Your choice of webserver will not protect you from poor coding on your part. So do yourself a favor and work with some standard stuff. It'll get your project up and running much faster and much better than reinventing the wheel without understanding the dynamics behind such a task. (Think early years of the railroad industry...those pesky wheels just kept on breaking...)

CGI? Well, that's the fun thing. Delphi can generate CGI too. Actually, you can even create an MS-DOS batch file and use it as CGI, as long as the server can execute the application. And I am reasonable familiar with CGI applications too. With CGI, the server sends any relevant data as input to the CGI application and it collects the output again, adjusts the headers and sends that back to the client.

I have used Apache in the past. My current webhost uses IIS so I know how to build websites for both already. And I must say it's all reasonable secure. But for me it's something experimental. Something that I want to have running on my own system. I want to build my own (small) webserver application and experiment with it. For real webhosting, I would still use either IIS or Apache and preferably have the site hosted by some experienced webhosting company. This project is just experimental, to check the most vulnerable parts of a webserver.

I'm not too worried about people having the sourcecode of anything I use in my webserver, anyways. If my webserver becomes insecure because people know it's sourcecode then it's just a bad design.

And recompiling my whole webserver just to add in a new feature? Well, I don't consider that to be a huge problem, since it won't be that huge. Besides, I can always build it in a more modular way. I've already experimented with a small webserver that can load ISAPI libraries and it's not that difficult to get CGI working from my application either. And yes, GET/POST and a few other requests are known to me. Am also familiar with running child processes, handling multiple threads, fibers even. Things like mutexes, critical sections, events and semaphores are also things I know a bit about. Race conditions can also be a bit troublesome, just like deadlocks. I'll probably have to build a time-out system too to prevent threads from running forever.

And no, I don't plan to make something better than Apache or IIS. I just want something simple as one simple, easy to distribute, package. It will probably end up with a little database functionality too, with the server generating pages to browse the data in maybe up to 5 different tables.

The whole server will be running on an old Pentium III system at 500 MHZ with 256 MB ram, about 5 GB of free diskspace and my router will be configured to allow access to this system through port 80. The challenge will be to have this system running as long as possible with a minimum of losses in memory or other resources. It's an experiment. The webserver isn't the final goal. Learning about security for webservers is. Basically it's a project with a lot of different aspects for someone who wants to learn some extreme programming.

/me Sex0rz Katja.

Ahhh screw you too... why can't you accept the fact that im a big lesbo and you can't have me, HT.

Well, back to the topic of security...


You ask if you write a program that listens on some port, port x, will that compromise your computer?

My answer is you will be compromised if you do some big foul-up and create a buffer-overrun condition that somehow manages to get code into the heap (not as easy to do if your attacker can't see the code at all) or if you overlook some special cases/states of your application and do not apply your rule enforcement across the entire application. (an example of this is hacking some feature in later and forgetting to update a few components with your modifications)

Otherwise simply opening a port does nothing.

It really just comes down to the service (web server, ftp server, ms p2p fileshare server, dns server, instant messenging server, your delphi application, etc) that owns that port being secure against attacks against that service/application itself.

Remember - the port is just a part of TCP/IP that allows your computer to easily communicate with other computers. It is the application that you write (that uses that port) that determines if you will have problems or not letting any user of the internet access it.


Just plan the application through and you should be alright...and be sure to test it and see if you can break it yourself to catch stuff you may have overlooked.