![[Image: TkmzXhn.png]](https://i.imgur.com/TkmzXhn.png)
Securing Your Website Against Hackers
[img]http://i.minus.com/ivrx6GdS8dZ5O.gif[/img]
Contents:
1) SQL Injection prevention
2) XSS Injection prevention
3) LFI Injection prevention
Note: I'm no PHP pro; there are usually better ways of doing stuff here. I'm focussing on showing you the ideas rather than telling you what to copy and paste etc.
[img]http://i.minus.com/ivrx6GdS8dZ5O.gif[/img]
SQL Injection
Is the art of manipulating user inserted SQL queries into being received by the server through the http, all the way to the DMBS to being executed, and all the way back to the client to display the malfunctioning content the attacker wants the website to display. SQL Injection will usually be used for:
1. Giving unauthorized access to hidden website areas (Common)
2. Providing hidden database information such as client details, passwords, and information (Common)
3. Serve as a DoS point in cases where an injection doesn't lead to database access (Less common)
4. Being bent to a client side attack (XSS), specifically stealing cookies and such. Every SQLi is an XSS. (Less common)
5. Grant arbitrary file reading with load_file() due to incorrect current MySQL user privilege placement (Rare: MySQL)
6. Grant complete ADMINISTRATOR/SYSTEM netuser privileges through the combination of a skilled injector and a vulnerable, unpatched Win server. (xp_cmdshell) (Rare: MSSQL 2000/2005)
7. Abuse Stacked Queries based injection to include multiple types of queries to be able to have complete database control: pulling, inserting, deleting, creating information at will. (Rare: ASP/.NET)
You don't want that, do you?
I'm going to tell you how to prevent this form of attack on your website. We're using the PHP/MySQL platforms.
Prepared statements
This is the best way of doing it. It's not the easiest, but when doing creative queries beyond the basic select GET ID value, you'll find that it is the best solution. The basic documentation regarding how to use this can be viewed here.
Basically:
mysqli_prepare ($connection variable{$con = mysqli_connect()}, string $query{SELECT priv FROM testUsers WHERE username=? AND password=?})
This code is pseudo. The red means stuff that is inside the variable, to make it more understandable. You then fetch the output of mysqli_prepare. Generally, you'd want to learn MySQLi (MySQL Improved) here, or PDO.
Limit Maximum Input Length
<?php
$get = $_GET['id'];
$len = 5;
if(strlen($get) > $len)
{
die("Illegal URL set of actions");
}
?>
If the input parameter is larger than five (every injection will be), the page will die.
Force Casting Input Variables
<?php
$get = (int)$_GET['id'];
?>
or
<?php
$get = intval($_GET['id']);
?>
The list goes on and on. There are a ton of ways to express what I'm saying here and how simple and effective this is. It's arguably my favorite method for SIMPLE stuff. You're going to face some issues when doing an INSERT query with legit English input ;)
Blacklisting
<?php
$get = $_GET['id'];
if(preg_match('/and|where|if|union|select|all|order|concat|group|schema/i', $get)) {
die("bad word detected :^)");
}
?>
Yeah, this way is sort of awful. I'm just explaining it to show you that it exists - blacklisting popular injection words. Please don't use this one!
mysql_real_escape_string()
In my beginning year, I used to jump to this function. Now I force myself to forget it. How to:
http://php.net/manual/en/function.mysql-...string.php
function will later be deleted on (php 5.5).
http://www.iodigitalsec.com/mysql_real_e...-problems/
Do NOT rely on mysql_real_escape_string(). However, if you do: set_charset('utf8'), and only then use it.
[img]http://i.minus.com/ivrx6GdS8dZ5O.gif[/img]
XSS Injection Prevention
XSS (Cross Site Scripting, C replaced the X because Cascade Style Sheets stole the CSS term. Dirtbags.) is the categorizing term for attacking the other end site of the Website formation = The Client. This means client sided Keyloggers, Cookie Stealers, XSSF shells and future shells (XSS shells), session fixation through URL parameters, ClickJacking, form grabbing, Phishing, JavaScript, BTC miners, browser crashers, browser exploit kits, victim becomes Proxy, XSS worms, DoS and DDoS (to client and server as one), AND MORE. Yeah, there's more.
To avoid this, you need to filter out what you let in. Remember: user input is the devil. You don't need any fancy statements or blacklists here.
htmlspecialchars() vs htmlentities()
Special characters will cover the most lethal of the characters, while entities will cover absolutely all of them. I'd recommend using the latter, but it doesn't block the ' sign by default, so if you use it, use it like this:
<?php
$get = $_GET['x'];
echo htmlentities($get, ENT_QUOTES);
?>
Popular Question:
When using a database, should you filter input BEFORE database insertion or AFTER insertion when you echo it?
Answer: This is subjective; both have issues. You might suffer some ugly character twists (double filtering, if you use gfc_magic_quotes etc), but it's okay to handle (compared to having to filter the same input OVER AND OVER again as it's unfiltered inside the database).
So yeah, my answer would be filter it before database insertion.
[img]http://i.minus.com/ivrx6GdS8dZ5O.gif[/img]
LFI Prevention
LFI (Local File Inclusion), as well as RFI (Remote File Inclusion)- or even RCE (Remote Code Execution), at times- all have a possibility of being executed from a single mistake: including user input. What are the possible consequences? Server ownage. Nothing more, nothing less; it's this dangerous.
No stress, though. It's very easy to prevent. If you're working with a bunch of PHP pages being displayed through a built-in formation that links around stuff and includes what is linked, all you have to do is to specify exactly the pages that can be included inside an array, and then later check whether the inclusion request actually has anything from that list.
<?php
$list = array('one.php', 'help.php', 'etc.php');
if(!in_array($_GET['include'], $list)
{
die("requested page doesn't exist");
}
else {
include($_GET['include']);
}
?>
Another way is to use open_baserdir and basically limit the ability of PHP to include files from other directories, but that isn't the best method (if the attacker includes an admin session file from the same dir, for example). You can review the process over here.
These are basically the basics. Of course, there is much more to learn and comprehend around website security. If there will be a demand, I'll release other tutorials regarding this subject.
- Written by Th3PonyWizard/Sonder
![[Image: vGscZ.gif]](https://i.imgur.com/vGscZ.gif)