A few ways a website could become hacked and defaced (info credits go to Simon Willison and others)
An unpatched operating system with vulnerabilities in system services (SSH daemons, web servers, other procceses).
Defence is to make sure you keep your packages up to date and avoid running anything exotic that might not be actively maintained.
XSS attacks. Make sure you have a deep understanding of what XSS is and how it works,
and ideally use a template language that escapes output by default to help avoid the most obvious problems.
SQL injection attacks. Make sure you use a library that paramaterises SQL queries and handles escaping correctly for you,
NEVER append strings together to create a SQL statement.
Sniffing your administrative username/password or even your authenticated cookie over an insecure WiFi network
- make sure you only ever send those things over HTTPS.
Brute force attacks on your administrative login screen - make sure you rate limit login attempts.
Guessing your server’s SSH password (or your admin interface password)
- use a one-time, random password stored securely in something like 1password and ideally don’t have SSH passwords at all,
use SSH public-key authentication instead.
Serving JavaScript on the page from another URL (e.g. an externally hosted JavaScript library or an advertising network)
which gets compromised.
It doesn’t matter how good your own site security is if you link to insecure JavaScript from a third party.
The top ten they try: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
After they probed your server for the application stack and aided by HTML, Javascript code,
URL pattern, hitting standard URL’s of admin pages & port scanning,
the hacker/defacer knows what (automated) exploit to launch against te website.
With CMS you should apply all patches, in that case you’d be OK.
Also check all input.output (validate),
Wrong assumptions often cause hacks and defacements to succeed:
User can see but not change HTML or JavaScript so client side logic cannot be tampered.
POST requests are secure because user can’t see what’s being passed to the server.
Unlike GET, the user can’t modify the parameters.
It is OK to send saved password back to a page because it appears as *****
Other common blunders:
-
Database fields become exposed to modification because the programmer choose to simply persist the entire object received from the user instead of only picking those fields that the user was allowed to modify from that page.
-
Having ajax methods such as getObject(int objectid) in Javascript with no corresponding validation on server side to find whether the requested object should be accessible to the current user.
L4me coding blunders will do the rest. Info credits: Quora Anonymous.
Just posted this as a warning for website owners/admins.
There is more how to prevent hacking and defacement.
SQL, XSS, Error Messages, block automated scripts, etc. etc.
Read more from my “From the URL scanning front” topic, please.
polonus (volunteer website security analyst and website error-hunter)