Implementing a whitelist of permitted services and hosts in a WordPress site

After a security review of our new WordPress site it was pointed out that we're vulnerable to "External Service Redirecton - DNS". Specifically, if a URL is entered into the "Your Name" field of our Contact 7 Form then the testers have found that: "It was possible to induce the application to perform server-side DNS lookups of arbitrary domain names"

The suggested remedial action is to implement a whitelist of permitted services and hosts and to block interaction not on this whitelist.

I'm something of a newbie when it comes to this, and it occured to me (perhaps wrongly!) that there may be different whitelists; one for those who cannot enter the site, and a separate for sites to which our server is allowed to speak. Or does a whitelist imply both ways?

Anyway, all help on this gratefully received and I'm imagining this is something that's been done a zillion times before!

I'm using IIS and would prefer that answer, although Apache related help just as good because I've realised I can kind of 'translate' how to do it once I've got the idea.

Incidentally, we definitely want to avoid editing the Contact 7 form's code too much becasue this may be lost when we upgrade, even though I dare say this would fix the issue. Unfortunately the latest version has the same problem, although will let the Contact 7 team know to look into this. Would ideally like to use another form for data collection of this sort although i'm a part of a team that prevents this!

And so, in the meantime it appears that a whitelist solution will likely do the trick, any ideas on how to do that anyway?

Thanks in advance
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dan McFaddenSystems EngineerCommented:
- What version of the Contact 7 Form are you using?
- Have you enabled the "Spam Filtering with Akismet" functionality.  This checks if the content of the field is spam or not.  I imagine this functionality includes doing a lookup because it talks with an API.  A quote from Contact 7's docs about this functionality:

When at least one of those options are set (remember, it’s recommended to set all of the options for accurate judgment), Contact Form 7 will send Akismet all of the sender’s input and the information relating to the submitting activity. Akismet will then judge whether this submission is likely to be spam.


Can you post the configuration of the "Your Name" field from the Admin section of the Contact 7 manager?

It sort of sounds like the text field is defined incorrectly in the Contact 7 plugin.

iaing1000Author Commented:
Hi Dan,

Brilliant, thanks for this, I'll have a look in the morning. Hopefully this will this clear things up.

Do you happebn to know how to configure a whitelist? Looks like this is going to be a requirement anyway,

Dan McFaddenSystems EngineerCommented:
I'm not sure what exactly is meant by white-listing "services and hosts."  IIS does have a feature called IP Address and Domain Restrictions which you can configure to allow or deny rules based on specific IP Addresses (or ranges) and/or Domains.

As for white-listing applications, IIS does not have any features that implement such controls over access.

In IIS Manager, if there is a physical directory where the Contact7 form exists, you can place a default DENY rule on all access and then setup rule or rule that would allow access for specific IPs or IP Ranges.  I do not recommend enabling the Domain part of the feature since it will consume additional resources in order to resolve DNS domains prior to implementing the rules.

Here is the tech docs from Microsoft for the IIS Feature:

If you can share more from the security review report, it may be possible that I can make some additional recommendations.

SD-WAN: Making It Work for You

As bandwidth requirements and Internet costs grow, businesses naturally want to manage budgets by reducing reliance on their most expensive connection types. Learn more about how to make SD-WAN work for your business in our on-demand webinar!

iaing1000Author Commented:
Thanks again Dan, wil lcome back to this later just got tied up with something. Much appreciated
iaing1000Author Commented:
Security Issue
External service interaction (DNS)

It was possible to induce the application to perform server-side DNS lookups of arbitrary domain names. The payload was submitted in the your-name parameter.
The application performed a DNS lookup of the specified domain.
The lookup was received from IP address xx.xx.xx.xx at 2017-Nov-11 10:56:47 UTC.

External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. However, in many cases, it can indicate a vulnerability with serious consequences.

In cases where DNS-based interactions can be triggered, it is normally possible to trigger interactions using other service types, and these are reported as separate issues. If a payload that specifies a particular service type (e.g. a URL) triggers only a DNS-based interaction, then this strongly indicates that the application attempted to connect using that other service, but was prevented from doing so by egress filters in place at the network layer. The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.

You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.

If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.

Whilst it is hard to demonstrate this particular finding as there is no visual response from the webserver, the request and response headers have been included which show the request that was made and also includes the time stamp. This could be correlated to the webservers DNS logs to further validate that a DNS request was made as a result of the request.
iaing1000Author Commented:

I've posted the specifics of the finding. Specifically, the long URL was submitted in the your-name field of our Contact 7 form (I dare say the same issue exists in other fields too of course). The description and recommendation I've discovered are lifted directly from the Portswigger site where External Service Interaction (DNS) is listed as a potential security flaw.

I'm simply trying to follow the recommendations and set up such a Whitelist. Another tricky thing is that this isn't an obvious one to test internally once we have a supposed fix (at least it's not clear to me anyway!), as it also states in the evidence section.

Hope that makes sense,

Dan McFaddenSystems EngineerCommented:
After reading thru the analysis posted, I would recommend investigating the configuration of the Contact7 form.  Where or who is the developer of the site?  I would present the above statement about the vulnerability to the person/team/company that developed the site for you and have them mitigate this issue.

Also, is this form available on the Internet or is this only an internal form?

Setting up rules in the "IP Address and Domain Restrictions" feature will be complicated (if not impossible) if this is an Internet facing site.  

Can you post the Evidence that they provided for this issue?  

Whilst it is hard to demonstrate this particular finding as there is no visual response from the webserver, the request and response headers have been included which show the request that was made and also includes the time stamp.

iaing1000Author Commented:
Hi Dan,

The site was developed by a separate company and we've been handed over the work although they will continue to edit parts of the WP site. Our experience (3 of us!) is really more databases and app development.

One of our jobs now is to get us through CHECK certification and an initial analysis of what we'd been left indicated 24 issues, of varying severity (critical, high, medium, low - although that's kind of a very subjective scale!) of which I've resolved 22. Mainly edits to wp_config, http headers, httpd.conf or IIS settings to do with SSL/TLS and similar, plus WP updates for the core and plugins and the addition of a 2FA plugin. All good so far but for two remaining, one of which is this (all of wihch were pretty much new to me).

The site is public facing on the internet. Will shortly post their transcription of the 'evidence'.

iaing1000Author Commented:
Here's what they supplied as evidence:

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html: charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: PHP/5.5.34
Link: <>; rel=""
Link: <>; rel=shortlink
Date: Mon, 20 Nov 2017 10:56:53 GMT
Connection: close
Content-Length: 27929
Dan McFaddenSystems EngineerCommented:
So, first a few questions:

- What version of WP?
- What version of the Contact Form 7?
- How many sites are running on the server?
- How IPv4 addresses are set up on the server?
- What protocols are bound to the site's IP Address?
- How are those protocols bound to the site's IP Address?

Unfortunately this is not an easy one to resolve.  "External service interaction" is also known as "Server Side Request Forgery (SSRF)" and is usually resolved down at the coding level.  Here's a little info about it:

- (scroll down to the "JavaScript, AJAX, and SPAs" section)

If you read thru the links above, they all speak of using code to address this specific vulnerability. So mitigating this issue would, most likely, require some type of code fix or plug-in fix on the Contact Form 7.  Again, I recommend inspecting the configuration of the form fields that are affected.

Most fixes involve input validation, use of Antiforgery tokens and sometimes jsut designing around it.

Also interesting to note, the in Wordpress sites (according to the article Understanding WordPress Security Vulnerabilities), SSRF constitutes less than 1% of the known vulnerabilities.

There are also a few other configuration items that I see, from a security standpoint, that have not been implemented at either the IIS Server scope or the site scope.

For example:
1. The HTTP Response Header "Server" is returning the server info "Microsoft-IIS/8.5"
--- this tells me that you are running Windows Server 2012 R2.
--- This header should be disabled
2.  The HTTP Response Header "X-Powered-By" is returning PHP info "PHP/5.5.34"
--- this tells me that you are using an old version of PHP (5.5.34 was release 30-MAR-2016) & is 32bit since 5.5.x support for x64 is only experimental.
--- IMO, this is a significant attack vector.  This header should, at least, be disabled!
3.  There are no advanced security HTTP Response headers setup.
--- Test your site's HTTP Response Headers at:
--- How to article:

Without knowing more about the Contact Form 7, it will be hard for me to make any further recommendations.

Hopefully some of this info helps.

iaing1000Author Commented:
Hi, thanks for this, here's some more details:

WP — 4.9.2
Contact Form 7 — 4.9.1
Just the one site running on the server
Just running from one IPv4 address
http & https are both bound on ports 8080 & 43 respectively (is this what you're asking?)

Some of the http header information we've now changed anyway since these cropped up in the list of initial 24 security concerns, although this is very useful to me with the links as well.

My suspicion is now that we go the input validation route because a) the IP whitelisting may be a hassle and b) if it fixes the issue then I'm less worried anyway and it'll 'pass'.

Looking back at your previous post, and before I grab it, were you referring to seeing how the your-name field appears in the admin.php file for the Contact 7 form or was there somewhere else I needed to look?

Thanks again
Dan McFaddenSystems EngineerCommented:
The HTTP & HTTPS ports.... why the non-standard configuration?   Default is HTTP on 80/tcp and HTTPS on 443/tcp.  On the site bindings, are you using "All Unassigned" for the IP address binding or have you specified the server's IP address.

My recommendation is to specify an IP address on the bindings.  The only time I recommend using the "All unassigned" option, is when implementing a catch-all site.  For example, in a web hosting provider scenario where you want to catch all 404s and serve up a default content not found page, in the event the hosted website does not define one.

Looking back at your previous post, and before I grab it, were you referring to seeing how the your-name field appears in the admin.php file for the Contact 7 form or was there somewhere else I needed to look?

Yes it was.

iaing1000Author Commented:
There would have been some odd legacy reason why these were changed. In any case these are now 80 & 443 respectivley - standardising makes sense. The IP address binding is currently set for All Unassigned, will need to look at this.

In the meantime I've installed the Akismet spam filtering free version and got the WP key etc to have it all working with the Contact Form 7. The collection for the your-name field is now appended with the akismet:author tag and the your-email with akismet:author_email tag. The upshot is that this correctly fails for their test case where name is suplied as "viagra-test-123" however it doesn't filter if the your-name field has a URL supplied. Which is what we're trying to filter out...

Before I go futher, is there anything specific I should be looking for in the admin.php file, e.g which function in particular?

Dan McFaddenSystems EngineerCommented:
You need to verify that the form is doing field validation, before POST'ing the data back to the site.

I assume that this form is only a contact form, where a user sends in data like first name, last name, email address, phone, etc.  Since the type of data expected is easy to define, you can check the data in all fields against a set of patterns.  Those patterns (RegEx) are well defined.

For example:
- a Your-Name field should not contain anything like a URL or IP address
- a Email Address field can be validated easily with a RegEx email pattern
- a Phone Number fields should contain only numbers, dashes.  The validate process can strip anyway characters as well.

The issue here is that the process of POST'ing data thru your form is allowing a remote user to pass commands into the host and the host is returning the output of that command.  The only way I can see addressing this issue is to make sure that the inbound form data is being validated before being submitted

Here is an article explaining what happens during an SSRF attack and how you can prevent them:

Dan McFaddenSystems EngineerCommented:
IMO (not a humble one), if there is not field data validation happening on the form, then the developer(s) who built the site and/or form(s) are at fault.

Again, most SSRF prevention will have to be done at the application code level.  Tweaking the configuration of IIS to try to mitigate SSRF, will not bring much value.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
iaing1000Author Commented:
That makes a lot of sense. Now that the Akismet looks as though it won't filter URLa, validating the form details in code must be the best step. Will have a look at that and see if that fixes it.

Thanks again
iaing1000Author Commented:
OK, now that I know where to aim I've made some great progress.

In the functions.php file for the Contact Form 7 I've put the following:

add_filter('wpcf7_validate_text', 'your_validation_filter_func', 999, 2);
add_filter('wpcf7_validate_text*', 'your_validation_filter_func', 999, 2);

function your_validation_filter_func($result, $tag) {
	$type = $tag['type'];
	$name = $tag['name'];

	if ('your-name' == $name) {
   	 	$the_value = $_POST[$name];
   	 	$myresult = substr($the_value, 0, 4);
   	 	if ($myresult == "Iain") {
     	   $result['valid'] = true;
   	 	} else {
    	    $result->invalidate($tag, "Test validation for text field");

	return $result;

Open in new window

Obvs this isn't the final version but it works exactly as I'd like and doesn't post out, insteadgiving a validation error on the field.

Now just need to adapt it to use a RegEx that denies URLs that I'll look up shortly. Then may as well apply the same logic to the email field wihch it transpires also has no validation!

...and maybe have a word with whoever wrote this to start with :-)
Dan McFaddenSystems EngineerCommented:
I would definitely address this issue with the Developers who created the site.  These type of issues are web design 101... always validate inbound form fields or you risk leaving a potential hole open on a publicly accessible website.

But it appears you have a plan for a solution.

iaing1000Author Commented:
Thanks for this Dan, much appreciated.
iaing1000Author Commented:
Thanks for this, got it all sorted months back now!

Just came across this issue whilst looking for something else and thought I ought to give feedback - excellent stuff :-)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft IIS Web Server

From novice to tech pro — start learning today.