what are the categories of attacks that can be handled during coding like sql injection?

Question

What are the types of categories of attacks that can be handled during coding or in code like sql injection and cross-site scripting (XSS) in a web app or native app ?

Edit : As the answers is on hold , I want only names of most common or top 5 which can be handled in coding not server(hosting) or network or os issues.

Edit 2 : I have narrowed it to categories of attacks due to hold.

Answer 1

The answer below is relative to SQL Injection and HTTP Response Splitting.

Such an exploit will occur when application(s) makes direct use of user input within the behavior of the application. This is considered bad practice and opens any application to multiple breaches for things such as Cross-site-scripting (XSS), Host Header Attacks (modifying the Host header within an HTTP request to perform malicious behavior).

So what do I mean by directly taking user input? Say for instance you have a simply form, containing a single Person ID field and a submit button. Once the submit button the system dynamically generates a SQL Query to match the user's desired information.

SELECT * FROM Users WHERE PersonID = '$person_id'

This query takes takes the incorrect assumption that the user ought to be trusted, which should never be the case. So what is a good step to take in your code in order to prevent this? Prepared Statements, Parameter queries whenever possible.

I common example taken from the wikipedia link above:

$mysqli = new mySqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
$$mysqli->real_escape_string($Username),
$$mysqli->real_escape_string($Password));
$mysqli->query($query);

---

Cross-site-scripting (XSS) is often mitigated by encoded special characters allowing the browser to display entities but not run them. Below is an nice list displaying how certain characters are encoded. I highly recommend visiting this article to read further about it or taking a look at the Web Vulnerability dictionary that I mentioned down below.

Do note that the same concept applies here as it does for SQL Injection. User input is NEVER to be trusted.

<?php
$name = $_GET['name'];
echo "Welcome $name<br>";
echo "<a href="http://xssattackexamples.com/">Click to Download</a>";
?>

Looking at the above example you'll notice $name being a stored variable which is being directly referenced to later in the code. Now instead of querying the name Bob (for example), the malicious user queries <script>alert('attacked')</script>. With the above code, this query would execute the above command in the web application (which could be FAR more serious than this).

---

HTTP Response Splitting

A hacker may be able to locate a header injection vulnerability which allows him to formulate a request that injects an entire HTTP body into the response and another second response body (might sound a bit confusing). Essentially the server would recognize this as two separate requests chained together -- which is why it is called HTTP Splitting as you're effectively splitting the server's response.

The reason why I have decided to place this vulnerability in this answer is because it is one of the easiest vulnerabilities to exploit which doesn't require an awful lot of knowledge and opens your application to major vulnerabilities such as XSS. This key characters to execute this vulnerability are %0d%0a -- more formally known as CRLF (Carriage Return and Line Feed) which is essential to many protocols as it marks the end of a line (EOL).

If your Web Application does not properly handle such characters with the methods mentioned above then a malicious user can have their input affect the server's behavior which is obviously something we do not want.

Let's take a look at a partial example:

http://www.yoursite.com/somepage.php?page=%0d%0a
Content-Type:text/html%0d%0aHTTP/1.1 200 OK%0d%0a
Content-Type:text/html%0d%0a%0d%0a%3Chtml%3EHacker Content%3C/html%3E

When the user clicks the above link who would then be served with the <html>Hacker Content</html> page. The interesting part? This is done through your server. Your vulnerable server is serving the victim this malicious content.

For more information regarding this I suggest reading this Acunetix CRLF Injection below and OWASP's HTTP Response Splitting article

---

Mitigating vulnerabilities on a web applications can be done in many ways however before looking into specific vulnerabilities it is best to look into the system structure and whether it itself is weak and open to attacks (many oversee this issue).

The rest is entirely obtainable over the internet. I encourage reading ALOT of articles from different authors when it comes to web application security.

A very useful link I found is this Web Vulnerabilities dictionary by Acunetix which provides well but not overly detailed descriptions about desired vulnerabilities, common remediation techniques along with community articles.