Hiawatha web server

exim22

Member
Joined
Feb 7, 2007
Messages
374
Reaction score
0
I need some tips on writing PHP GCI and fine-tuning security when hosting on my laptop as a home web server with wifi router.
 

davidktw

Arch-Supremacy Member
Joined
Apr 15, 2010
Messages
13,547
Reaction score
1,301
I need some tips on writing PHP GCI and fine-tuning security when hosting on my laptop as a home web server with wifi router.

From the standpoint of CGI, much of the security lies on the CGI processes, not so much of the web server since all computational responsibly is with the processing engines.

For PHP, if you are using CGI, then your security concern is how to harden your PHP engine. It's not all that different from all other web servers less of using mod_php in Apache. The rest mostly rely on CGI/FastCGI protocol.

The passing of information between the web server and the processing engine is via HTTP headers and environment variables. So the responsibility is quite well segregated.

As for the security features in Hiawatha, it will be good to see anyone else can offer tips :)
 

jf

Moderator
Moderator
Joined
Jan 1, 2000
Messages
7,220
Reaction score
0
This is an interesting choice! There's not much that can be said about the security, unfortunately. The "HOWTO" (https://www.hiawatha-webserver.org/howto) doesnt even mention it; and all you have are a few lines in the manual (https://www.hiawatha-webserver.org/manpages), which dont exactly give u the sort of confidence that a lot of effort and thought has been put into this. If you rely on just a proxy in front of your application/s to give u security... u are approaching things the wrong way. If you use it as part of a layered approach... maybe.

So the security features that it purports to have (according to "Features") are this:
Security is one of the key features of this webserver. Besides support for SSL (via PolarSSL), Hiawatha offers protection against SQL injections, Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF/XSRF) and DoS attacks. Banning of bad behaving clients and limiting CGI runtime are examples of Hiawatha's unique security features.

And the mentions in the manual:
PreventCSRF = yes|no
Prevent Cross-site Request Forgery by ignoring all cookies sent by a browser when following an external link to this website. This setting can cause problems for users who use tools to hide/remove the Referer HTTP header string while browsing. Please note that this protection is not 100% safe.
Default = no, example: PreventCSRF = yes
PreventSQLi = yes|no
Prevent SQL-injection by detecting injections and denying the request via a 409 response. It is important to understand that the detection of SQL injections is done by best effort. There is no 100% guarantee that all SQL injections are blocked. Note that using this feature can have a negative effect on the performance of your webserver. Use with caution. See also BanOnSQLi.
Default = no, example: PreventSQLi = yes
PreventXSS = yes|no
Prevent cross-site scripting via the URL by replacing a less-then, greater-then, quote or double-quote in the URL with an underscore.
Default = no, example: PreventXSS = yes

So - PreventCSRF will not work for certain exploits that are already out there and known (better to rely on your application to do this! that's in fact, the only way you can be sure), no specific details for PreventSQLi... except for his note on "no 100% guarantee", and I really dont know about that PreventXSS behaviour - it can be irritating (now for your case if u're just using it for urself... u shouldnt be too worried about that if u're not really looking to use those characters that it replaces!), and wont be comprehensive.

For banning, see the various Ban* directives. Those would look effective against certain dumb clients... but it's definitely going to add some processing time to the server itself.
 
Important Forum Advisory Note
This forum is moderated by volunteer moderators who will react only to members' feedback on posts. Moderators are not employees or representatives of HWZ Forums. Forum members and moderators are responsible for their own posts. Please refer to our Community Guidelines and Standards and Terms and Conditions for more information.
Top