Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WordPress 4.8.1 still vulnerable to Host Header Attack

learnwebdevelopment.review

Post reply on HN
Print view View original

1–10 of 14 posts

Re: WordPress 4.8.1 still vulnerable to Host Header Attack

#3

Post by kels »

I get where WordPress is coming from by not fixing this issue since it's an Apache thing. But since Apache's default value causes this to happen I think the framework should try to protect its users. The normal user that had their WordPress installed using an application installer on a shared host isn't going to know about this issue.

Re: WordPress 4.8.1 still vulnerable to Host Header Attack

#4

Post by wolfgang42 »

kels wrote: post #3

I get where WordPress is coming from by not fixing this issue since it's an Apache thing. But since Apache's default value causes this to happen I think the framework should try to protect its users. The normal user that had their WordPress installed using an application installer on a shared host isn't going to know about this issue.

Fortunately, shared hosts aren't likely to be vulnerable to this attack: in that case, the Host header will be used to identify which shared site to run, so if an attacker changes it they'll get a different site. This vulnerability is only a problem if WordPress is installed as the default site (or has a dedicated IP address), in which case unknown values of the Host header will be passed directly to it.

Re: WordPress 4.8.1 still vulnerable to Host Header Attack

#7

Post by KekDemaga »

kels wrote: post #3

I get where WordPress is coming from by not fixing this issue since it's an Apache thing. But since Apache's default value causes this to happen I think the framework should try to protect its users. The normal user that had their WordPress installed using an application installer on a shared host isn't going to know about this issue.

As mentioned in a previous discussion by calibas, PHP.net has this disclaimer:

"Note: Under Apache 2, you must set UseCanonicalName = On and ServerName. Otherwise, this value reflects the hostname supplied by the client, which can be spoofed. It is not safe to rely on this value in security-dependent contexts."

So it seems to be clearly a Word Press issue.

Re: WordPress 4.8.1 still vulnerable to Host Header Attack

#8

Post by tombrossman »

kels wrote: post #3

I get where WordPress is coming from by not fixing this issue since it's an Apache thing. But since Apache's default value causes this to happen I think the framework should try to protect its users. The normal user that had their WordPress installed using an application installer on a shared host isn't going to know about this issue.

With Nginx I've always used this for the first server block to defeat host header attacks, taken from the h5bp boilerplate server configs[0]:

  server {
    listen 80 default_server;
    return 444;
  }
Is something like this necessary for Apache as well? If yes, what are others using? (ignoring the non-standard but effective 444 return code)

[0]https://github.com/h5bp/server-configs-nginx

Re: WordPress 4.8.1 still vulnerable to Host Header Attack

#9

Post by TazeTSchnitzel »

kels wrote: post #3

I get where WordPress is coming from by not fixing this issue since it's an Apache thing. But since Apache's default value causes this to happen I think the framework should try to protect its users. The normal user that had their WordPress installed using an application installer on a shared host isn't going to know about this issue.

A given server can effectively have any hostname because of Host:, and that might even be desirable, so Apache's behaviour doesn't seem reasonable.
Post reply on HN