Developers fix multitude of vulnerabilities in Apache HTTP Server • Hacker News Board

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#111

Post by trulyme » Sun, Sep 26, 2021, 6:55 PM UTC

arp242 wrote: post #99

trulyme wrote: post #60

Earlier quoted context omitted.

And Apache supports .htaccess files which are great for hosting (nginx doesn't, afaik).

Not by default, but since nginx is pretty flexible you can implement support for it, and it seems like people have. There are some downsides with .htaccess files though; since it can change you need to at least check if it was modified since the last request, and since it's recursive (i.e. /foo/.htaccess applies to /foo/bar/file.txt) you may need to check several locations. Basically, it's a lot of stat() calls for e…

I don't agree with the downsides - what you are describing is simply a bad implementation of this mechanism. At the very least, the files could only be checked every 5 seconds, or inotify or similar mechanism could be used.

The main upside is that it is possible for sysadmin to allow 3rd party users to change parts of http server config via ftp (!). And last I checked, php was dominating web landscape - I would argue that the convenience of deploying plays a large part in this.

Plugins... If it is not part of original app, can I trust it will stay available? I might as well use Apache instead.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#112

Post by nocsi » Mon, Sep 27, 2021, 1:24 PM UTC

iBotPeaches wrote: post #8

This was an interesting security patch that marked the first time in my memory that updating Apache led to an immediate regression. A few hours after taking this upgrade many systems experienced such strange timeout errors. Connections were low and couldn't pinpoint the misleading behavior that looked like a slowloris attack, with no connections. Half a day later with no resolution in research a new patch [1] was ava…

It might be because they had patch cycle commitments. Ideally you want this stuff to be tucked into the regular release cycle. It costs companies a shit load of money to release and out of band update, esp when security related

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#113

Post by cestith » Mon, Sep 27, 2021, 10:29 PM UTC

onli wrote: post #65

cestith wrote: post #14

Earlier quoted context omitted.

Lots of companies that have been around a while and haven't replaced legacy applications still run those behind the web server they were designed to run behind. Moving to another server seems simple until you actually try to do that with a handful of 15-year-old sites with proxy rules, rewrites, custom headers, and such in one server's central config file and a bunch of per-directory access files. Technical debt is a…

That's not debt. Those are working configurations on a fully supported web server with active development. There is zero reason to change them.

When the reason a team can't unbind from one technology in favor of county and that reason is old decisions that we won't make today, that's a form of debt. If you're choosing to stick white Apache for a good reason it's not debt.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#114

Post by onli » Tue, Sep 28, 2021, 2:54 PM UTC

cestith wrote: post #113

onli wrote: post #65

Earlier quoted context omitted.

That's not debt. Those are working configurations on a fully supported web server with active development. There is zero reason to change them.

When the reason a team can't unbind from one technology in favor of county and that reason is old decisions that we won't make today, that's a form of debt. If you're choosing to stick white Apache for a good reason it's not debt.

I don't think we disagree here. If old systems stay with a legacy technology and do other work instead of changing that foundation, then staying with the legacy technology can become technical debt - not the decision itself, back in the day.

But Apache is not a legacy system and still a completely valid choice, next to alternatives like nginx and caddy that have their own advantages and disadvantages. There is no reason to swap Apache out by default, apart from maybe sometimes in specific situations.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#115

Post by lanstin » Tue, Oct 05, 2021, 3:23 PM UTC

rastafang wrote: post #86

lanstin wrote: post #59

Earlier quoted context omitted.

Presumably you'll have less features. I wrote a web server (in the 90s, so forgivable?), and I only implemented GET and query string for the API data, and nothing fancy, no cache headers, no redirects, no multipart, no gzip, no content-encoding negotiation, etc. Some of the APIs it hosted were ultimately hacked (thru encryption of the encrypted query string via plain DES, and the key was determined), but, so far as I…

Not impossible that your web server was 100% secure, but I doubt it because I think that I have never seen a server that didn't eventually need security patches.

I left the company and then about ten years later it was turned off. It was in C but was pretty mature framework, not C style strings. And the code was just “validate assumption for parsing, else return error” then “parse the next few bytes else return error”. Very simple small number of parameters, explicit length limits everywhere. And it was a public AOL end point so widely and continually attacked by people. I was there for maybe 7 years after deploying it and nothing (known) happened in that time.