islba.co.at

Do we all need a Web Application Firewall?

Really, what is this WAF (web application firewall) doing for me? Simple as that, it creates a set of rules designed to protect your website. A Web Application Firewall (WAF) is a tool that looks at the information in an HTTP request and blocks the request if it is malicious. This prevents malicious requests that are trying to exploit vulnerabilities in applications such as WordPress from being able to reach the vulnerable code.

Blocking unwanted web traffic from accessing your site, Protecting against some kind of hacks, brute force attacks, DDoS attacks, cross-site scripting, SQL/PHP/Code Injection, Cache Poisoning, HTTP Response Splitting, Directory Traversal, File Injection/Inclusion, Null Byte Injection, WordPress exploits (such as revslider, timthumb, fckeditor), Exploits (such as c99shell, phpshell, remoteview, site copier), PHP information leakage and a range of malicious requests, bad bots, spam, and other nonsense.

And when you thinking, “My Website Isn’t a Target for a Hack” oh yeah maybe.

The bottom line: No matter how unlikely you think a hack on your website might be. The website itself is a potential target, just because it’s out there, https isn’t enough, this goes along for strong passwords, 2FA and certificates too, these days.

Always Remember!
“its a hostile world, be prepared to fight”

username or email flanked with 2FA #GDPR

As a matter of fact there is more to do than type in a username and a password to achieve a getting some kind a close to #GDPR compliance feeling or recomandation. Strongly I get a feeling that state of the art #GDPR will be soon a real pain in the ass for all of us using software for making things happen. Think about it!

Be honest to yourself, is protecting a login with username and password enough in in these days? Sure not, so use a 2^nd factor for authentication and get yourself and your clients some kind of a state of the art protected feeling.

As far as I’ve seen it here #WordPress allows you to choose between your username and your email for login. Well there is no easy way out unless you use some kind of LDAP services to manage that struggle. On the other hand you can force your users to write their usernames for 429 login applications down, cuz they will not memorize it, or let them use their email and their email only for login. Always supported or flanked by a 2FA.

The only thing you have to do is, temper a little bit with the code in your child-themes.

The file you have to edit is functions.php

eine weitere Absicherung

Im Grundsatz sollten doch alle Bereiche der WordPress Internetpräsenz für jedermann zugänglich sein?

JaNein denn es gibt Ausnahmen. Zum einen ist der LogIn Bereich zusätzlich zu schützen. Zum anderen sollten Daten die am WebServer abgelegt sind/werden, auf die nicht jeder zugreifen darf, zusätzlich geschützt sein.

Erreichen kann man dies auf einfachste Weise und auf einem technischen Basis Level mit einem Verzeichnisschutz.

Dieser Verzeichnisschutz ist verantwortlich, dass der Zugriff zu bestimmten Bereichen nur nach einer Passwortabfrage möglich ist.

Ein solcher Verzeichnisschutz zur Steigerung der Sicherheit für WordPress kann man jederzeit einrichten.

Man Sollte dies auch relativ schnell umsetzen.

Der hier beschriebene Verzeichnisschutz besteht aus 2 Teilen, der Konfigurationsdatei und der Passwortdatei in der die Anmeldeinformationen hinterlegt sind.

Zu beachten und bedenken gilt, man schützt immer das Verzeichnis, indem die Konfigurationsdatei liegt.

Das Passwort in der Passwortdatei sollte auf jeden Fall verschlüsselt gespeichert werden. Wichtig ein sog. “Passwort Generator” ist nicht zweckdienlich es wird ein sog. “Hash Generator” benötigt.

Den so erhaltenen verschlüsselten Wert fügt man dann in die Passwortdatei ein. Sobald der Upload auf den Webserver erfolgreich durchgeführt ist, sollte der Verzeichnisschutz aktiv sein.

Mit dieser Maßnahme schafft man eine weitere serverseitige Hürde die Angreifer überwinden müssen. Der Schutz von Verzeichnissen wird nicht mehr nur dem eingesetzten CMS überlassen.

still painfull but in the end its not working well

Content-Security-Policy HTTP response header helps to reduce XSS risks on modern browsers by declaring, which dynamic resources they are allowed to load.
The Content-Security-Policy header allows to restrict how resources such as JavaScript, CSS, or pretty much anything that the browser loads.

What types of attacks does Content-Security-Policy help reduce?
Content-Security-Policy was first designed to reduce the attack surface of Cross Site Scripting (XSS) attacks and further on also to protect against other forms of attack such as Click Jacking.

Referring to Recital 83 GDPR, Security of Processing GDPR, when you touch personal data processing there is no way out of
trying everything to set security up to state of the art. Of Course always taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected.
Always have a look at GDPR Art5.1.f, Art25, Art32.2 too.

So a guess out in the wild, WordPress will still be used and serving content with script-src ‘unsafe-inline’ and ‘unsafe-eval’ till someone is gonna fix this without breaking that whole CMS.