tokkonopapa / WordPress-IP-Geo-Block

A WordPress plugin that will blocks any comment, pingback and trackback spams posted from outside your nation. And it will also protect against malicious access to the login form, admin area and XML-RPC from undesired countries.
http://www.ipgeoblock.com/
29 stars 14 forks source link

Question: ip-geo-block-auth-nonce query string #51

Closed Jeff-Lewis closed 5 years ago

Jeff-Lewis commented 5 years ago

Hi @tokkonopapa, great plug-in and thank you for your work!

In an effort to keep query stings short and limited, would it be possible to put 'ip-geo-block-auth-nonce' in a cookie instead of the query string? Alternatively, can we have the option to rename it? Is it possible to disable the query string modification and nonce check?

I wanted to get your opinion before we look into doing any customization of your plugin.

Thank you, Jeff

tokkonopapa commented 5 years ago

Hi @Jeff-Lewis,

... in a cookie instead of the query string?

No.

Think the case that you got an e-mail including a malicious link shortened by such as Bitly and targeted at your site.

When you logged into your site as an admin and click the link on the e-mail, then the attack might be success because authentication information was in your cookie.

So "nonce in cookie" can be vulnerable and it's called CSRF.

Alternatively, can we have the option to rename it?

Yes, I can. I'll try it in the next release.

Thank you for your asking.

tokkonopapa commented 5 years ago

Add a new filter hook ip-geo-block-auth-key to change the name of the key for nonce on 3.0.16.

Jeff-Lewis commented 5 years ago

Thanks @tokkonopapa . What are your thoughts on a cookie's SameSite attribute?

tokkonopapa commented 5 years ago

Hi @Jeff-Lewis,

Thank you for the information about same-site cookies. I have to investigate some scenarios if it is a silver bullet against CSRF by reading the draft, because CSRF is often combined with XSS, SQLI and etc.

Section 5 says:

It is, however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other attack vectors such as cross-site scripting.

Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are idempotent, etc) to mitigate the risk more fully.

Anyway, I keep tracking this topic.