Zaseths Guide For Not Getting Breached

Everyone likes a happy server, right? So let's avoid breaches and get to a professional level.
This tutorial also includes how to search for the c99 & r57 shell (These shells were on HendrixCP that the ''hacker'' uploaded.)
Apparently I also ''hacked'' HendrixCP. This is not true. I was actually fighting the ''hacker'' over the VPS.
**// Discord: Zaseth#7550
**// Skype: live:king.daan1 (Please don't resolve my Skype :p)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Some cool stuff:
https://piwik.org/
https://github.com/swfobject/swfobject
http://www.sqlparser.com/sql-injection-detector/
http://gavinmiller.io/2015/fixing-sql-injection-vulnerabilities/
https://www.owasp.org/index.php/Top_10_2017-Top_10
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Blind_SQL_Injection
https://www.owasp.org/index.php/Blind_XPath_Injection
https://www.owasp.org/index.php/XPATH_Injection
https://www.owasp.org/index.php/LDAP_Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Server-Side_Includes_(SSI)_Injection
https://www.owasp.org/index.php/Injection_problem
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
https://medoo.in/
https://github.com/Maikuolan/phpMussel
https://www.cloudbric.com/main.php
https://github.com/djeraseit/PHP-backdoor-detector
https://github.com/emposha/PHP-Shell-Detector
https://www.cloudflare.com/
http://suhosin.org/stories/index.html
https://www.netsparker.com/
https://laravel.com/
https://security.appspot.com/vsftpd.html
http://phpsec.org/projects/phpsecinfo/index.html
https://httpd.apache.org/docs/current/suexec.html
https://httpd.apache.org/docs/current/misc/security_tips.html
https://www.owasp.org/index.php/Category:Attack
http://sparta.secforce.com/
https://sourceforge.net/projects/dirbuster/
https://www.metasploit.com/
https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework
https://www.thc.org/thc-hydra/
https://wpscan.org/
https://www.nginx.com/resources/wiki/
https://github.com/rezasp/joomscan
https://varnish-cache.org/
---------------------------------------------------
Frequently asked questions // General stuff
What is a 0day?: A 0day is an exploit where the developers are unknown of. 0day exploits are mostly private (Not shared.) but there is a big chance of it getting leaked. So you should still update.
I have seen CPPS's using Drupal. If you decide to use Drupal, please don't use Drupal v7.x and keep it updated daily.
I have XSS (Cross-site scripting) on my website. Should I fix it?: Yes. You should. There's a tool called Xenotic XSS Exploit Framework and you can do a ton of scary things with it.
There is a function in MySQL to grant every user admin privileges. You should not do this because if you get hit by SQL injection that user also has admin privileges.
Did you know you can actually change the name of your PHPMyAdmin URL login? -> https://www.tecmint.com/change-secure-phpmyadmin-login-url-page/ This will avoid some stuff.
Should I use nulled (illegal / pirated) forum / wordpress software?: You should first check the source code for any shells and malicious code. It still is illegal though and updating can be hard.
Should I use MD5?: No. MD5 is a mistake. (Just like SHA-1 so also don't use that.) just stick to Bcrypt (https://en.wikipedia.org/wiki/Bcrypt) your database can be leaked, but the passwords will be secure. So there's nothing to worry about the passwords. You could also encrypt user's IP addresses before storing it in the database.
Should I use HTTPS?: Well yes. Every data will be insecure. And it's free. (https://www.openssl.org/) Please keep it updated (http://heartbleed.com/)
What are the risks of having an old Apache version?: Well there are a lot of horrible Apache exploits. A famous one is called ''KillApache'' which is a Memory Exhaustion exploit (Remote DoS) And I hope this will wake you up of not using an old version: https://www.cvedetails.com/vulnerability-list/vendor_id-45/Apache.html
Using a script to TEMP ipban someone giving a lot of requests could also be smart.
How do you remove the Apache Version is Server Header?: There actually is a bug in this, but it is possible! http://apache-http-server.18135.x6.nabble.com/header-unset-server-does-not-work-td5006287.html You need mod_security (Which is actually in this tutorial!) so if you have that, set it to this: https://pastebin.com/raw/xE6eBgyq
Wordpress plugins can also be vulnerable. So keep these updated as well!
A simple list of admin urls can be found here: https://pastebin.com/raw/CXngT5F0
Having a fail login limit on WP-ADMIN is also smart.
Using strip_tags to avoid injection.
htmlspecialchars also works fine to avoid sql injection:
$query = htmlspecialchars($query);
$query = mysql_real_escape_string($query);
---------------------------------------------------
Anti DDOS:
index.php: https://pastebin.com/raw/mHAaJW9u
anti_ddos.php: https://pastebin.com/raw/XWJtnHUp
Or use: https://github.com/damog/planetalinux/blob/master/www/principal/suscripcion/lib/antiflood.hack.php
Or use: https://blazingfast.io/
---------------------------------------------------
Monitoring POST Requests:
$http_host    = $_SERVER['HTTP_HOST'];
$server_name  = $_SERVER['SERVER_NAME'];
$remote_ip    = $_SERVER['REMOTE_ADDR'];
$remote_host  = $_SERVER["REMOTE_HOST"];
$request_uri  = $_SERVER['REQUEST_URI'];
$http_ref     = $_SERVER['HTTP_REFERER'];
$query_string = $_SERVER['QUERY_STRING'];
$user_agent   = $_SERVER['HTTP_USER_AGENT'];
$post_vars = clean(file_get_contents('php://input'));
To deny all POST Requests (Not recommended), add this in httpd.conf:
# deny all POST requests
<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_METHOD} POST
    RewriteRule .* - [F,L]
</IfModule>
If you want to redirect to a specific page:
RewriteRule .* /custom.php [R=301,L]
---------------------------------------------------
FastCGI PHP Configuration (Not needed but it can be useful)
Make sure required packages are installed (httpd-devel and apr-devel required to compile mod_fastcgi), enter:
yum install libtool httpd-devel apr-devel apr
Then:
cd /opt
wget http://www.fastcgi.com/dist/mod_fastcgi-current.tar.gz
Then:
tar -zxvf mod_fastcgi-current.tar.gz
cd mod_fastcgi-2.4.6/
cp Makefile.AP2 Makefile
Now this part is important, so please read!!!:
for 32 bit system, enter:
make top_dir=/usr/lib/httpd
make install top_dir=/usr/lib/httpd

for 64 bit system, enter:
make top_dir=/usr/lib64/httpd
make install top_dir=/usr/lib64/httpd

Now for part 2:
vi /etc/httpd/conf.d/mod_fastcgi.conf
Add an entry to it like this:
LoadModule fastcgi_module modules/mod_fastcgi.so
Save & close file and restart with:
service httpd restart

Now for a small part 3:
You need to disable mod_php5, to do so:
mv /etc/httpd/conf.d/php.conf /etc/httpd/conf.d/php.conf.disable

Now we are going to create a shell script:
Create a script as follows in /var/www/cgi-bin/php.fcgi (or put in your virtual domain cgi-bin directory)
#!/bin/bash
# Shell Script To Run PHP5 using mod_fastcgi under Apache 2.x
# Tested under Red Hat Enterprise Linux / CentOS 5.x
### Set PATH ###
PHP_CGI=/usr/bin/php-cgi
PHP_FCGI_CHILDREN=4
PHP_FCGI_MAX_REQUESTS=1000
### no editing below ###
export PHP_FCGI_CHILDREN
export PHP_FCGI_MAX_REQUESTS
exec $PHP_CGI
Set permission, type:
chmod +x /var/www/cgi-bin/php.fcgi

You need to use AddHandler and Action directives for mod_fastcgi:
 <directory "/var/www/html">
   Options -Indexes FollowSymLinks +ExecCGI
    AllowOverride AuthConfig FileInfo
    AddHandler php5-fastcgi .php
    Action php5-fastcgi /cgi-bin/php.fcgi
    DirectoryIndex index.php index.html
    Order allow,deny
    Allow from all
</directory>
And finally:
service httpd restart
---------------------------------------------------
Avoid PHP_SELF XSS (URI-BASED XSS):
<form name="test" action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>" method="post">
---------------------------------------------------
Avoid exploits:
Always keep your services up to date. (SSH, FTP)
For FTP usage, use WinSCP
Never share any password.
Use bcrypt.
---------------------------------------------------
Apache Security:
Open: httpd.conf
Set:
ServerSignature Off
ServerTokens Prod
Save File
Restart Apache: /etc/init.d/httpd restart
---------------------------------------------------
ALWAYS Remove info.php!!!
---------------------------------------------------
sqlite3.ini:
Solution 1) mv /etc/php.d/sqlite3.ini /etc/php.d/sqlite3.disable
Solution 2) rm /etc/php.d/sqlite3.ini
---------------------------------------------------
Compiled in Modules:
./configure --with-libdir=lib64 --with-gd --with-mysql --prefix=/usr --exec-prefix=/usr \
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share \
--includedir=/usr/include --libexecdir=/usr/libexec --localstatedir=/var \
--sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info \
--cache-file=../config.cache --with-config-file-path=/etc \
--with-config-file-scan-dir=/etc/php.d  --enable-fastcgi \
--enable-force-cgi-redirect
---------------------------------------------------
Restrict PHP Information Leakage:
Edit /etc/php.d/secutity.ini
Set: expose_php=Off
Test: curl -I http://www.Yoursite.xdd/index.php
---------------------------------------------------
Minimize Loadable PHP Modules (Dynamic Extensions):
Type these commands:
cd /etc/php.d/
mv gd.{ini,disable}
/sbin/service httpd restart
To enable php module called gd, enter:
mv gd.{disable,ini}
/sbin/service httpd restart
---------------------------------------------------
Log All PHP Errors:
Edit /etc/php.d/security.ini and set the following directive:
display_errors=Off
log_errors=On
error_log=/var/log/httpd/php_scripts_error.log
---------------------------------------------------
log all php errors to a log file:
vi /etc/php.ini
error_log = /var/log/php-scripts.log
display_errors = Off
Restart options:
systemctl restart httpd.service
restart php7.0-fpm
/etc/init.d/httpd restart
See logs: sudo tail -f /var/log/php-scripts.log
---------------------------------------------------
Disallow Uploading Files (This will get rid of some PHP shells. Not guaranteed though.):
Edit /etc/php.d/security.ini and set the following directive to disable file uploads for security reasons:
file_uploads=Off
If users of your application need to upload files, turn this feature on by setting upload_max_filesize limits the maximum size of files that PHP will accept through uploads:
file_uploads=On
# user can only upload upto 1MB via php
upload_max_filesize=1M
---------------------------------------------------
Turn Off Remote Code Execution:
Edit /etc/php.d/security.ini and set the following directive:
allow_url_fopen=Off
allow_url_include=Off
---------------------------------------------------
Enable SQL Safe Mode:
Edit /etc/php.d/security.ini and set the following directive:
sql.safe_mode=On
Either way:
magic_quotes_gpc=Off
---------------------------------------------------
Control POST Size:
Edit /etc/php.d/security.ini and set the following directive:
; Set a realistic value here
post_max_size=1K
Edit, httpd.conf and set the following directive for DocumentRoot /var/www/html:
<directory /var/www/html>
<limitExcept GET POST>
Order allow,deny
</limitExcept>
## Add rest of the config goes here... ##
</directory>
---------------------------------------------------
Resource Control (DoS Control):
Edit /etc/php.d/security.ini and set the following directives:
# set in seconds
max_execution_time =  30
max_input_time = 30
memory_limit = 40M
---------------------------------------------------
Install Suhosin Advanced Protection System for PHP:
http://suhosin.org/stories/index.html
Commands:
cd /opt
wget http://download.suhosin.org/suhosin-0.9.27.tgz
yum install php-devel
cd suhosin-0.9.27
phpize
./configure
make
make install
echo 'extension=suhosin.so' > /etc/php.d/suhosin.ini
Restart options:
service httpd restart
If you are using lighttpd, enter:
service lighttpd restart
To verify: php -v
It should show Suhosin VersionHere
---------------------------------------------------
PHP Fastcgi / CGI – cgi.force_redirect Directive:
Edit /etc/php.d/security.ini and set the following directive:
; Enable cgi.force_redirect for security reasons in a typical *Apache+PHP-CGI/FastCGI* setup
cgi.force_redirect=On
---------------------------------------------------
Disabling Dangerous PHP Functions:
set list of functions in /etc/php.d/security.ini:
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
---------------------------------------------------
Session Path:
The default is as follows under RHEL/CentOS/Fedora Linux:
session.save_path="/var/lib/php/session"
; Set the temporary directory used for storing files when doing file upload
upload_tmp_dir="/var/lib/php/session"
IMPORTANT: Make sure path is outside /var/www/html and not readable or writeable by any other system users:
ls -Z /var/lib/php/
---------------------------------------------------
Keep PHP, Software, And OS Up to Date:
Solution 1) yum update
Solution 2) apt-get update && apt-get upgrade
---------------------------------------------------
Write Protect Apache, PHP, and, MySQL Configuration Files:
Examples:
chattr +i /etc/php.ini
chattr +i /etc/php.d/*
chattr +i /etc/my.ini
chattr +i /etc/httpd/conf/httpd.conf
chattr +i /etc/
The chattr command can write protect your php file or files in /var/www/html directory too:
chattr +i /var/www/html/file1.php
chattr +i /var/www/html/
---------------------------------------------------
Use Linux Security Extensions (such as SELinux):
First do this command:
getsebool -a | grep httpd
If output is:
httpd_enable_cgi --> on
Do this command:
setsebool -P httpd_enable_cgi off
---------------------------------------------------
Install Mod_security:
First, setup Mod_security with the following commands:
yum install mod_security
vi /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
And set this in the .conf file:
SecRuleEngine On
Then restart with the following command:
service httpd restart
To test:
tail -f /var/log/httpd/error_log
Important code snippets for conf files:
## A few Examples ##
# Do not allow to open files in /etc/
SecFilter /etc/# Stop SQL injection
SecFilter "delete[[:space:]]+from"
SecFilter "select.+from"
---------------------------------------------------
Use Firewall To Restrict Outgoing Connections:
In this example, allow vivek user to connect outside using port 80 (useful for RHN or centos repo access):
/sbin/iptables -A OUTPUT -o eth0 -m owner --uid-owner vivek -p tcp --dport 80 -m state --state NEW,ESTABLISHED  -j ACCEPT
---------------------------------------------------
Watch Your Logs & Auditing:
Check Apache log:
tail -f /var/log/httpd/error_log
grep 'login.php' /var/log/httpd/error_log
egrep -i "denied|error|warn" /var/log/httpd/error_log
Check PHP log:
tail -f /var/log/httpd/php_scripts_error.log
grep "...etc/passwd" /var/log/httpd/php_scripts_error.log
---------------------------------------------------
To make you scared what PHP Backdoors can do:
Download files
Upload files
Install rootkits
Set a spam mail servers / relay server
Set a proxy server to hide tracks
Take control of server
Take control of database server
Steal all information
Delete all information and database
Open TCP / UDP ports and much more
You must be asking: How Do I Search PHP Backdoors?
HendrixCP got hit by c99 shell & r57.
To search these:
grep -iR 'c99' /var/www/html/
grep -iR 'r57' /var/www/html/
find /var/www/html/ -name \*.php -type f -print0 | xargs -0 grep c99
grep -RPn "(passthru|shell_exec|system|base64_decode|fopen|fclose|eval)" /var/www/html/
---------------------------------------------------
Do you want to know how to generate SSH keys?:
https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
Do you need some secure passwords?: http://passwordsgenerator.net/
---------------------------------------------------
Now you will read a long list of all the popular and it's fixes.
---------------------------------------------------
Denial of Service (MySQL)
In order to fix this problem, you should first determine what causes this. Some suggestions:
•Check max_connections settings in the MySQL configuration file, which is located in the MySQL installation folder for Windows systems, and /etc/my.cnf for Unix/Linux-like systems.
•Do not use persistent connections on your code. This is possible only for PHP systems by disabling it through the setting on php.ini.mysql.allow_persistent=Off
•Ensure you explicitly close the database connections.
•Ensure you close opened database connections when an error occurs in the code.
•Lower the MySQL connection timeout.
---------------------------------------------------
Directory Listing (Apache)
1.Change your server configuration file. A recommended configuration for the requested directory should be in the following format:
<Directory /{YOUR DIRECTORY}>
    Options FollowSymLinks
</Directory>
Remove the Indexes option from configuration. Do not forget to remove MultiViews, as well.
2.Configure the web server to disallow directory listing requests.
3.Ensure that the latest security patches have been applied to the web server and the current stable version of the software is in use.
^ This is serious though. With dirbuster and an Apache Vulnerability Wordlist you can discover a lot of critical things.
---------------------------------------------------
Insecure Crossdomain.xml (Can result in malicious .swf upload)
Configure your Crossdomain.xml to prevent access from everywhere to your domain.
Insecure usage:
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Secure usage:
<cross-domain-policy>
<allow-access-from domain="domain.com" />
<allow-access-from domain="www.domain.com" />
<allow-access-from domain="*.domain.com" />
</cross-domain-policy>
---------------------------------------------------
Directory Listing (Nginx)
1.Change your nginx.conf file. A secure configuration for the requested directory should be similar to the following:
location /{YOUR DIRECTORY} {
    autoindex off;
}
2.Configure the web server to disallow directory listing requests.
3.Ensure that the latest security patches have been applied to the web server and the current stable version of the software is in use.
---------------------------------------------------
WS_FTP Log File Detected
If it is a file required by the application, change its permissions to prevent public users from accessing it. If it is not, then remove it from the web server.
---------------------------------------------------
.DS_Store File Found
If it is a file required by the application, change its permissions to prevent public users from accessing it. If it is not, then remove it from the web server.
---------------------------------------------------
Backup File Disclosure
Do not store backup files on production servers.
---------------------------------------------------
Insecure JSONP Endpoint
•Make endpoints return the HTTP header Content-Disposition with filename attribute, forcing a file download.
Content-Disposition: attachment; filename=f.txt
•To be also protected from content sniffing attacks, prepend the reflected callback with /**/.
---------------------------------------------------
Internal IP Address Disclosure
First, ensure this is not a false positive. If it is not a false positive, consider removing it.
---------------------------------------------------
Reflected File Download
•Add Content-Disposition header with filename attribute in the HTTP response:
Content-Disposition: attachment; filename=f.txt
---------------------------------------------------
SQL Injection
A robust method for mitigating the threat of SQL injection-based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built-in libraries for this. Wherever possible, do not create dynamic SQL queries or SQL queries with string concatenation.
---------------------------------------------------
Apache Multiple Choices Enabled
1.Change your server configuration file to disable spelling module. A recommended configuration for the requested directory should be in the following format:
<Directory /{YOUR DIRECTORY}>
    CheckSpelling Off
</Directory>
---------------------------------------------------
Apache MultiViews Enabled
1.Change your server configuration file. A recommended configuration for the requested directory should be in the following format:
<Directory /{YOUR DIRECTORY}>
    Options FollowSymLinks
</Directory>
Remove the MultiViews option from configuration.
---------------------------------------------------
Database Error Message Disclosure
Do not provide any error messages on production environments. Save error messages with a reference number to a backend storage such as a text file or database, then show this number and a static user-friendly error message to the user.
---------------------------------------------------
Form Hijacking
Do not allow user input to control the form tag's attributes. If the dynamic usage is necessary then use whitelisting.
---------------------------------------------------
Internal Server Error
The impact may vary depending on the condition. Generally this indicates poor coding practices, not enough error checking, sanitization and whitelisting. However, there might be a bigger issue, such as SQL injection.
---------------------------------------------------
Passive Web Backdoor Detected
1.Remove the identified passive web backdoor from your web server.
2.You should investigate how this passive backdoor is placed on your system. There may be another critical vulnerability on your system that allows this placement.
---------------------------------------------------
Programming Error Message
Do not provide error messages on production environments. Save error messages with a reference number to a backend storage such as a log, text file or database, then show this number and a static user-friendly error message to the user.
---------------------------------------------------
Username Disclosure (MySQL)
•Error messages should be disabled.
•Remove this kind of sensitive data from the output.
---------------------------------------------------
Version Disclosure (Nginx)
Add the following line to your nginx.conf file to prevent information leakage from the SERVER header of its HTTP response:
server_tokens off
---------------------------------------------------
Version Disclosure (mod_ssl)
Configure your web server to prevent information leakage from the SERVER header of its HTTP response. To apply configuration, first make sure you have headers_module installed.
Add the following line to load the headers module in the httpd.conf
    LoadModule headers_module modules/mod_headers.so
After headers_module is loaded, edit or include the following lines of config in the httpd.conf
    ServerSignature Off
    ServerTokens Prod
<IfModule mod_headers.c>
    Header unset Server
</IfModule>
---------------------------------------------------
Source Code Disclosure (PHP)
1.Confirm exactly what aspects of the source code are actually disclosed; due to the limitations of this type of vulnerability, it might not be possible to confirm this in all instances. Confirm this is not an intended functionality.
2.If it is a file required by the application, change its permissions to prevent public users from accessing it. If it is not, then remove it from the web server.
3.Ensure that the server has all the current security patches applied.
4.Remove all temporary and backup files from the web server.
PHP code in .html file won't work.
HTML code in .php file will work.
---------------------------------------------------
Anonymous Ciphers Supported
1.Configure your web server to disallow using anonymous ciphers.
For Apache, you should modify the SSLCipherSuite directive in the httpd.conf.
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
---------------------------------------------------
Apache Server-Status Detected
Comment out the Location/server-info section from Apache configuration file httpd.conf (for Redhat, Centos, Fedora) or apache2.conf (for Debian, Ubuntu).
---------------------------------------------------
Base Tag Hijacking
Do not allow user input to control the base tag. Whitelist it if the dynamic usage is necessary. Content-Security-Policy (CSP) base-uri directive can also help you prevent to change the <base> tag element. The base-uri directive defines the URIs that a user agent may use as the document base URL.
Content-Security-Policy: base-uri 'self'
---------------------------------------------------
Critical Form Send to HTTP
All sensitive data should be transferred over HTTPS rather than HTTP. Forms should be served over and form actions also should target HTTPS. All aspects of the application that accept user input, starting from the login process, should only be served over HTTPS.
---------------------------------------------------
Critical Form Served over HTTP
All sensitive data should be transferred over HTTPS rather than HTTP. Forms should be served over HTTPS. All aspects of the application that accept user input, starting from the login process, should only be served over HTTPS.
---------------------------------------------------
CVS Detected
Do not leave CVS repository files on production environments. If there is a business requirement to do so, implement access control mechanisms to stop public access to CVS repository files.
---------------------------------------------------
Frame Injection
•Where possible do not use users' input for URLs.
•If you definitely need dynamic URLs, make a list of valid accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs which are located on accepted domains.
---------------------------------------------------
HTTP Header Injection
Do not allow newline characters in input. Where possible, use strict whitelisting.
---------------------------------------------------
Insecure HTTP Usage
Configure your webserver to redirect HTTP requests to HTTPS.
For Apache, you should have modification in the httpd.conf.
# redirect all HTTP to HTTPS
<VirtualHost *:80>
       ServerAlias *
       RewriteEngine On
       RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>
---------------------------------------------------
Invalid SSL Certificate
Fix the problem with your SSL certificate to provide secure communication between your website and its visitors.
---------------------------------------------------
Insecure Transportation Security Protocol Supported (SSLv3)
•For Apache, adjust the SSLProtocol directive provided by the mod_ssl module. This directive can be set either at the server level or in a virtual host configuration.
SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
•For Nginx, locate any use of the directive ssl_protocols in the nginx.conf file and remove SSLv3.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
---------------------------------------------------
Open Redirection
•Where possible, do not use users' input for URLs.
•If you definitely need dynamic URLs, use whitelisting. Make a list of valid, accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs those are located on the trusted domains.
---------------------------------------------------
Open Redirection (DOM based)
•Where possible, do not use users' input for URLs.
•If you definitely need dynamic URLs, use whitelisting. Make a list of valid, accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs those are located on the trusted domains.
---------------------------------------------------
RSA Private Key Detected
•Remove this kind of sensitive data from the output.
---------------------------------------------------
Stack Trace Disclosure (Python)
Configure your application not to provide detailed error pages in production environments. Save all information regarding the error to a backend storage, such as a log or a text file, and show a friendly custom error page to the user.
---------------------------------------------------
Sublime SFTP Config File Detected
Restrict access to this file or remove it from the web server.
---------------------------------------------------
Weak Ciphers Enabled
1.For Apache, you should modify the SSLCipherSuite directive in the httpd.conf.
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
---------------------------------------------------
Blind Cross-site Scripting
The issue occurs because the browser interprets the input as active HTML, JavaScript or VBScript. To avoid this, output should be encoded according to the output location and context. For example, if the output goes in to a JavaScript block within the HTML document, then output needs to be encoded accordingly. Encoding can get very complex, therefore it's strongly recommended to use an encoding library such as OWASP ESAPI and Microsoft Anti-cross-site scripting.
---------------------------------------------------
Expression Language Injection
Apply input validation best practices to ensure there are no EL meta characters("${" and "#{") in the input.
---------------------------------------------------
Local File Inclusion
•If possible, do not permit file paths to be appended directly. Make them hard-coded or selectable from a limited hard-coded path list via an index variable.
•If you definitely need dynamic path concatenation, ensure you only accept required characters such as "a-Z0-9" and do not allow ".." or "/" or "%00" (null byte) or any other similar unexpected characters.
•It's important to limit the API to allow inclusion only from a directory and directories below it. This ensures that any potential attack cannot perform a directory traversal attack.
---------------------------------------------------
Server-Side Request Forgery (AWS)
•Where possible, do not use users' input for URLs.
•If you definitely need dynamic URLs, use whitelisting. Make a list of valid, accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs those are located on the trusted domains.
---------------------------------------------------
Server-Side Request Forgery (elmah MVC)
•Where possible, do not use users' input for URLs.
•If you definitely need dynamic URLs, use whitelisting. Make a list of valid, accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs those are located on the trusted domains.
In addition to above, apply the following changes in your web.config file to disable remote access to the Elmah:
<appSettings>
    <add key="elmah.mvc.requiresAuthentication" value="true" />
    <add key="elmah.mvc.allowedRoles" value="Admin" />
</appSettings>
---------------------------------------------------
Server-Side Request Forgery (elmah)
Apply the following changes in your web.config file to disable remote access to the Elmah.axd error log:
<elmah>
     <security allowRemoteAccess="no"/>
</elmah>
You can also use ASP.NET's own authorization mechanism to protect your Elmah.axd error log from attackers. The following configuration makes your Elmah.axd error log viewable by only authorized Administrators:
<configuration>
  <location path="elmah.axd">
    <system.web>
      <authorization>
        <allow roles="Administrators"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>
</configuration>
---------------------------------------------------
Server-Side Request Forgery (MySQL)
•Where possible, do not use users' input for URLs.
•If you definitely need dynamic URLs, use whitelisting. Make a list of valid, accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs those are located on the trusted domains.
---------------------------------------------------
Server-Side Request Forgery (SSH)
•Where possible, do not use users' input for URLs.
•If you definitely need dynamic URLs, use whitelisting. Make a list of valid, accepted URLs and do not accept other URLs.
•Ensure that you only accept URLs those are located on the trusted domains.
---------------------------------------------------
Stored Cross-site Scripting
The issue occurs because the browser interprets the input as active HTML, JavaScript or VBScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically the output location is HTML. Where the output is HTML, ensure all active content is removed prior to its presentation to the server.
Prior to sanitizing user input, ensure you have a pre-defined list of both expected and acceptable characters, with which you will populate a whitelist. This list needs only be defined once and should be used to sanitize and validate all subsequent input.
There are a number of pre-defined, well structured whitelist libraries available for many different environments; good examples of these include OWASP Reform and Microsoft Anti cross-site scripting libraries.
---------------------------------------------------
XML External Entity Injection
Multiple fixes: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet
---------------------------------------------------
Local File Inclusion
•If possible, do not permit file paths to be appended directly. Make them hard-coded or selectable from a limited hard-coded path list via an index variable.
•If you definitely need dynamic path concatenation, ensure you only accept required characters such as "a-Z0-9" and do not allow ".." or "/" or "%00" (null byte) or any other similar unexpected characters.
•It's important to limit the API to allow inclusion only from a directory and directories below it. This ensures that any potential attack cannot perform a directory traversal attack.
---------------------------------------------------
Backup Source Code Detected
This is dependent on the information obtained from source code. Uncovering these forms of vulnerabilities does not require high levels of skills. However, a highly skilled attacker could leverage this form of vulnerability to obtain account information for databases or administrative panels, ultimately leading to control of the application or even the host the application resides on.
---------------------------------------------------
Basic Authorization over HTTP
Move all of your directories which require authentication to be served only over HTTPS, and disable any access to these pages over HTTP.
---------------------------------------------------
Certificate is Signed Using a Weak Signature Algorithm
You'll need to generate a new certificate request, and get your CA to issue you a new certificate using SHA-2.
---------------------------------------------------
Cookie Not Marked as Secure
Mark all cookies used within the application as secure. (If the cookie is not related to authentication or does not carry any personal information, you do not have to mark it as secure.)
---------------------------------------------------
Cross-site Scripting
<form name="test" action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>" method="post">
The issue occurs because the browser interprets the input as active HTML, JavaScript or VBScript. To avoid this, output should be encoded according to the output location and context. For example, if the output goes in to a JavaScript block within the HTML document, then output needs to be encoded accordingly. Encoding can get very complex, therefore it's strongly recommended to use an encoding library such as OWASP ESAPI and Microsoft Anti-cross-site scripting.
---------------------------------------------------
Cross-site Scripting (DOM based)
•Untrusted data should only be treated as displayable text. Never treat untrusted data as code or markup within Javascript code.
•Avoid use of HTML rendering properties/methods. (e.g., innerHTML, outerHTML, document.write ). Instead use innerText or textContent.
•Always encode Javascript and delimit untrusted data as quoted strings when entering the application.
•Don’t evaluate JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse().
---------------------------------------------------
Cross-site Scripting via Remote File Inclusion
The issue occurs because the browser interprets the input as active HTML, Javascript or VbScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically, the output location is HTML. Where the output is HTML, ensure all active content is removed prior to its presentation to the server.
---------------------------------------------------
Database User Has Admin Privileges
Create a database user with the least possible permissions for your application and connect to the database with that user. Always follow the principle of providing the least privileges for all users and applications.
There is a function in MySQL to grant every user admin privileges. You should not do this because if you get hit by SQL injection that user also has admin privileges.
---------------------------------------------------
Out of Band XML External Entity Injection
•StAX and XMLInputFactory:
Set the javax.xml.stream.isSupportingExternalEntities property to false.
•.NET 3.5:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
•.NET 4.0:
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
XmlReader reader = XmlReader.Create(stream, settings);
•PHP:
libxml_disable_entity_loader(true);
---------------------------------------------------
Out-of-date Version (MySQL)
Please upgrade your installation of MySQL to the latest stable version.
---------------------------------------------------
Password Transmitted over HTTP
All sensitive data should be transferred over HTTPS rather than HTTP. Forms should be served over HTTPS. All aspects of the application that accept user input, starting from the login process, should only be served over HTTPS.
---------------------------------------------------
SVN Detected
Do not leave SVN repository files on production environments. If there is a business requirement to do so, implement access control mechanisms to stop public access to SVN repository files.
You can also use Export if you do one time deployments, instead of a checkout.
---------------------------------------------------
Trace.axd Detected
Apply the following changes on your web.config file to disable ASP.NET tracing:
<System.Web>
     <trace enabled="false" />
</System.Web>
---------------------------------------------------
Unrestricted File Upload
•Never accept a filename and its extension directly without having a white-list filter.
•If there is no need to have Unicode characters, it is highly recommended to only accept alpha-numeric characters and only one dot as an input for the file name and the extension.
•Limit the file size to a maximum value in order to prevent denial of service attacks.
•Uploaded directory should not have any "execute" permission.
•Don't rely on client-side validation only.
---------------------------------------------------
Weak Basic Authentication Credentials
Do not use weak passwords, which are short, default, common or easy to guess. Implement a strong password policy.
---------------------------------------------------
WebDAV Directory Has Write Permissions
Restrict access for method PUT or if it's not being used, consider disabling it.
---------------------------------------------------
Code Evaluation (Apache Struts)
Do not accept input from end users that will be directly interpreted as source code. If this is a business requirement, validate all input to the application by removing any data that could be directly interpreted as Apache Struts source code.
---------------------------------------------------
Code Evaluation (Perl)
Do not accept input from end users that will be directly interpreted as source code. If this is a business requirement, validate all input to the application by removing any data that could be directly interpreted as Perl source code.
---------------------------------------------------
Code Evaluation (PHP)
Do not accept input from end users that will be directly interpreted as source code. If this is a business requirement, validate all the input on the application and remove all the data that could be directly interpreted as PHP source code.
---------------------------------------------------
Command Injection
Before invoking system commands within an application, consider using an API, which allows you to separate commands and parameters. This can avoid many of the problems associated with command execution. See the external references for some examples. If this is not possible, whitelist all input and encode it in accordance with the underlying subsystem. (e.g. if it is Windows, then you need to escape from cmd.exe control characters)
---------------------------------------------------
Remote File Inclusion
•Wherever possible, do not allow the appending of file paths as a variable. File paths should be hard-coded or selected from a small pre-defined list.
•Where dynamic path concatenation is a major application requirement, ensure input validation is performed and that you only accept the minimum characters required, for example, "a-Z0-9", and that you filter out and do not allow characters such as ".." or "/" or "%00" (null byte) or any other similar multifunction characters.
•It's important to limit the API to only allow inclusion from a directory or directories below a defined path.
---------------------------------------------------
Bash Command Injection Vulnerability (Shellshock Bug)
Upgrade your system by following these instructions: https://access.redhat.com/solutions/1207723
---------------------------------------------------
Blind Command Injection
Before invoking system commands within an application, consider using an API, which allows you to separate commands and parameters. This can avoid many of the problems associated with command execution. See the external references for some examples. If this is not possible, whitelist all input and encode it in accordance with the underlying subsystem. (e.g. if it is Windows, then you need to escape from cmd.exe control characters)
---------------------------------------------------
Code Execution via File Upload
•Never accept a filename and its extension directly without having a white-list filter.
•Uploaded directory should not have any "execute" permission.
---------------------------------------------------
Code Execution via WebDAV
Remove write permissions from this directory or disable WebDAV if it's not being used.
---------------------------------------------------
OpenSSL Heartbleed
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
---------------------------------------------------
Out of Band Code Evaluation (PHP)
Do not accept input from end users that will be directly interpreted as source code. If this is a business requirement, validate all the input on the application and remove all the data that could be directly interpreted as PHP source code.
---------------------------------------------------
Out of Band Command Injection
Before invoking system commands within an application, consider using an API, which allows you to separate commands and parameters. This can avoid many of the problems associated with command execution. See the external references for some examples. If this is not possible, whitelist all input and encode it in accordance with the underlying subsystem. (e.g. if it is Windows, then you need to escape from cmd.exe control characters)
---------------------------------------------------
Out of Band SQL Injection
A robust method for mitigating the threat of SQL injection-based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built-in libraries for this. Wherever possible, do not create dynamic SQL queries or SQL queries with string concatenation.
---------------------------------------------------
Remote Code Execution and DoS in HTTP.sys (IIS)
Upgrade your system by following these instructions https://support.microsoft.com/en-us/help/3042553/ms15-034-vulnerability-in-http.sys-could-allow-remote-code-execution-april-14,-2015
---------------------------------------------------
Protecting Web Applications SQL Injection

Surely, there must be a way to simply sanitize user input and ensure an SQL injection is infeasible.  Unfortunately, that is not always the case.  There are perhaps an infinite number of ways to sanitize user input, from globally applying PHP's addslashes() to everything (which may yield undesirable results), all the way down to applying the sanitization to "clean" variables at the time of assembling the SQL query itself, such as wrapping the above $_GET['id'] in PHP's mysql_escape_string() function.  However, applying sanitization at the query itself is a very poor coding practice and difficult to maintain or keep track of.  This is where database systems have employed the use of prepared statements.

Prepared Statements

When you think of prepared statements, think of how printf works and how it formats strings.  Literally, you assemble your string with placeholders for the data to be inserted, and apply the data in the same sequence as the placeholders.  SQL prepared statements operate on a very similar concept, where instead of directly assembling your query string and executing it, you store a prepared statement, feed it with the data, and it assembles and sanitizes it for you upon execution.  Great!  Now there should never be another SQL injection again.  So why, then, are SQL injection attacks still, for over 14 years, constantly one of the biggest and most prevalent attack methods?

Insecure SQL Queries are a Problem

Simply put, it perhaps boils down to web application developer laziness and lack of education and awareness.  Insecure SQL queries are so extremely easy to create, and secure SQL queries are still mildly complex (or at least more complex than generic and typical in-line and often insecure queries).  In the example above, a malicious hacker can inject anything he or she desires in the same line as the SQL query itself.

Example and Explanation of an SQL Prepared Statement

However, with prepared statements, there are multiple steps.  No major database system operates like printf (with everything occurring within the same statement on the same line).  MySQL, directly, requires at least two commands (one PREPARE and one EXECUTE).  PHP, via the PDO library, also requires a similar stacking approach, such as the following:

$stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ?");

$stmt->execute(array($username, $password));

At first glance, this is not inherently problematic and, on average, increases each SQL query by only an extra line or two.  However, as this requires extra caution and effort on behalf of already tired and taxed developers, often times they may get a little lazy and cut corners, opting instead to just use the easy procedural mysql_query() as opposed to the more advanced object-oriented PDO prepare().

Beside of this many developers just stick with what they know to get the job done and they generally learn the easiest and most straightforward way to execute SQL queries rather than showing genuine interest in improving what they know. But this could also be an issue of lack of awareness.

Deeper Into the Rabbit Hole of SQL Injection Security

Say, however, this isn't the case of lazy developers, or even lack of prepared statements -- or, more precisely, say the software itself and its security is out of your hands.  Perhaps it is impractical or infeasible to completely secure the SQL queries in the code you use (by one comparison, Drupal has had over 20,000 lines of code committed, WordPress has had over 60,000 lines, and Joomla! has had over 180,000 lines), or, it may simply be impossible because it is encoded or so.  Whatever the case is, if you do not have control over the code you may need to employ different, more advanced "outside the box" protections.

Non Development Related SQL Injection Protection

Running Updated Software

First and foremost, always ensure you are running the most up-to-date software you can.  If you are using WordPress or any other CMS framework, keep it updated!  The same goes for PHP, your web server software such as Apache and nginx, and your database server (MySQL, Postgres, or others).  The more recent the version of  your software is, the less chance of having a vulnerability, or at least a widely-known one.  This also extends down to your other software as well, such as SSH, OpenSSL, Postfix, and even the operating system itself.

Block URLs at Web Server Level

Next, you should employ methods to ensure you are as minimally vulnerable to potential SQL injection attacks as possible.  You could perhaps go for a quick and easy match against common SQL query keywords in URLs and just simply block them.  For example, if you ran Apache as your web server, you could use the following two mod_rewrite lines in your VirtualHost directive, as explained below:

RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC]

RewriteRule (.*) - [F]

This is indeed quite clever, but it does not protect against everything.  SQL injection parameters can still be passed via POST values or other RESTful-type URLs, not to mention there are tons of different ways to bypass this kind of generic blacklisting.

Securing the Database and Privileges

You can also ensure your database itself is as secure as possible.  In the information security field, there exists a concept known as the principle of least privilege.  Effectively, this principle states that a user or program should have only the absolute very least amount of privileges necessary to complete its tasks.  We already do this practically every day with Linux file permissions, so the concept is in no way foreign, and is equally applicable to databases.  There is probably no reason why your log table should have anything beyond INSERT privileges, so you should not simply GRANT ALL PRIVILEGES because it is easier.

Segregating Sensitive and Confidential Data

Similarly, you might consider separation of data as a defense in depth approach, rather than conglomeration it into a single source.  When you step back and think about it, it is probably not a very wise idea to keep your (hopefully PCI-compliant) customer credit card data stored in the same database as your forums, which are running an outdated and highly vulnerable version of phpBB, right?  Not only would the principle of least privilege be very applicable in this situation, but even going so far as to entirely separate out your more sensitive data is a very sage approach.  To think about it another way, would you keep all your most important paperwork inside your house, or would you keep some in a safe deposit box, too?  The same concept applies with sensitive data.

Analyzing HTTP Requests Before Hitting the Web Application

Another option is the use of more detailed firewall systems.  Typically this might include some adaptive solution that rides on top of iptables or ipfw (depending if you are using Linux or a BSD variant, respectively), or perhaps a reactive Host Intrusion Detection System (HIDS) such as OSSEC, although these are often more complicated than desired and not exactly purpose-built for these uses.  Instead, you may wish to utilize a Web Application Firewall, which is designed specifically for these tasks.  While there exist several enterprise-level solutions that are both a WAF and database firewall (sitting between your web application and your database), there are many open-source solutions, such as ModSecurity and IronBee, that perform remarkably well.

The Truth about SQL Injection Web Vulnerability

There exists no real magic wand answer to fix SQL injections and protect your web applications from them, although PHP is attempting a more brute force approach of their own.  As of PHP 5.5, procedural MySQL is deprecated and soon to be removed entirely, which will require future software projects to switch either to MySQLi or PDO MySQL in order to continue to work.  This is good since it forces developers into a system that handles prepared statements with relative ease, although it still requires the use of stacking a few operations.  However, as many developers operate within a coding golf style; attempting to complete work in as few lines or characters as possible, many unfortunately will still opt for a single-line straight query over a two-line prepare.

There still exist other options to account for any development shortcomings, including but not limited to privilege limitations, data separation, web application firewalls, and many other approaches.  But until these options are as consistently employed as SQL injection attacks, we indeed may never see the day that injection-style attacks escape the OWASP's Top 10 list.  Be the change that is needed to ensure data and web application security, and keep your databases safe from SQL injections!