Any config tricks to stop site from framing us?

Yesterday, I discovered that someone had registered a site (basically
taking our domain name and adding a word to it) and then framed our
whole site in theirs. By that I mean it’s a full iframe job, with no
toolbars showing.

Not sure what they’re up to, but I’d like to stop it. I know I can use
a framebuster, but I’m wondering what I can do on the nginx.conf end to
stop them dead in their tracks so not an ounce of our bandwidth goes to
them.

Thanks for any advice.

One possibility (not Nginx related directly) is to block their IP
address
at the firewall level from even getting to your server.

On Tue, Dec 3, 2013 at 4:13 PM, Ian E. [email protected]
wrote:


nginx mailing list
[email protected]
nginx Info Page

Ilan B.
Chief Technology Officer

6300 NE 1st Ave., Suite 203
Ft. Lauderdale, FL 33334
(954) 771-0914

http://www.twitter.com/time4learning
http://www.facebook.com/Time4Learning

Time4Learning.com - Online interactive curriculum for home use, PreK-8th
Grade.
Time4Writing.com - Online writing tutorials for high, middle, and
elementary school students.
Time4Learning.net - A forum to chat with parents online about kids,
education, parenting and more.
spellingcity.com - Online vocabulary and spelling activities for
teachers,
parents and students.

On 2013-12-03 16:15, Ilan B. wrote:

One possibility (not Nginx related directly) is to block their IP
address at the firewall level from even getting to your server.

Or add a deny ###.###.###.### to the server block?

If they’re using an iframe rather than a proxy then IP tricks won’t
help.

Using the X-FRAME-OPTIONS header is probably your best bet [1]

Hope that helps,
Branden

[1]

That’s a good point, thanks.

On Tue, Dec 3, 2013 at 4:32 PM, Branden V. [email protected]
wrote:

On Tue, Dec 3, 2013 at 4:18 PM, Ian E. [email protected] wrote:

nginx mailing list
[email protected]
nginx Info Page


nginx mailing list
[email protected]
nginx Info Page

Ilan B.
Chief Technology Officer

6300 NE 1st Ave., Suite 203
Ft. Lauderdale, FL 33334
(954) 771-0914

http://www.twitter.com/time4learning
http://www.facebook.com/Time4Learning

Time4Learning.com - Online interactive curriculum for home use, PreK-8th
Grade.
Time4Writing.com - Online writing tutorials for high, middle, and
elementary school students.
Time4Learning.net - A forum to chat with parents online about kids,
education, parenting and more.
spellingcity.com - Online vocabulary and spelling activities for
teachers,
parents and students.

On Tue, Dec 03, 2013 at 04:13:03PM -0500, Ian E. wrote:

Hi there,

Yesterday, I discovered that someone had registered a site (basically
taking our domain name and adding a word to it) and then framed our
whole site in theirs. By that I mean it’s a full iframe job, with no
toolbars showing.

nginx sees the http request coming from the client.

Look at the http headers that you see getting to your nginx, when you
request your site directly.

Look at the http headers that you see getting to your nginx, when you
go to their site.

Play “spot the difference”.

Most likely, the only some-bit reliable difference is in the Referer:
header. But maybe you can see something else, when you use the browsers
that you care about.

Not sure what they’re up to, but I’d like to stop it. I know I can use
a framebuster, but I’m wondering what I can do on the nginx.conf end to
stop them dead in their tracks so not an ounce of our bandwidth goes to
them.

You can’t, reliably.

You can, for browsers that send a Referer: header of their site, return
different content – either a simple rejection using something like
Module ngx_http_referer_module; or tailored content that indicates
what you think of the framing site, or whatever else you can imagine.

f

Francis D. [email protected]

On Tue, Dec 3, 2013 at 4:46 PM, Ian E. [email protected]
wrote:

Thanks. Just did a cursory look, but does the header allow some sites to
frame? e.g. letting stumbleupon do it but not others?

No I don’t believe that’s the case. If the browser supports it, it
should stop anyone from iframing, but you’re under the mercy of the
browser implementation AFAIK – so maybe Google’s Chrome has some big
money deals with service providers like stumbleupon, for example (pure
speculation). There are other options listed in there such as
JavaScript tricks to verify the “self” frame is the same as the
“parent” frame. So you can also have a secondary check like that.

On 2013-12-03 16:39, Francis D. wrote:

nginx sees the http request coming from the client.
header. But maybe you can see something else, when you use the

You can’t, reliably.

You can, for browsers that send a Referer: header of their site,
return
different content – either a simple rejection using something like
Module ngx_http_referer_module; or tailored content that indicates
what you think of the framing site, or whatever else you can imagine.

Thanks for the info. I’ll have to take a look. I’m also hoping to get
them shut down as I’ve talked to their registrar. I’m hoping they
grabbed a whole bunch of domains to vampire and not just mine. If it was
just us, that’d be creepy

On 2013-12-03 16:32, Branden V. wrote:

Thanks. Just did a cursory look, but does the header allow some sites
to frame? e.g. letting stumbleupon do it but not others?

Sorry I misinterpreted your question. The header does not support
specifying specific hosts, for example, that you want to allow
iframing from.

Using the JavaScript technique, perhaps something could be done to
ensure window.parent.location.href matches some pattern or list of
hosts. I haven’t implemented anything like that before, though.

Hope that helps,
Branden