If you have read our previous posts<\/a>, in two posts we talk bot the security issues of websites and web apps. For all too many companies, it\u2019s not until after<\/em>\u00a0a security breach has occurred that web security best practices become a priority. During my years working as an IT Security professional, I have seen time and time again how obscure the world of web development security issues can be to so many programmers.<\/p>\n Now a day, SQL Injection represents a serious threat to Internet security for various dynamic Web applications residing on the Internet. These web applications drive many vital processes in various web-based businesses. As the use of the Internet for various online services grows, security threats on the Web are also increasing. There is a universal need for all dynamic web applications and this universal need is the need to store, retrieve or manipulate information from a database. Most systems that manage databases and their requirements, such as MySQL Server and PostgreSQL, use SQL as the language. The flexibility of SQL makes it a powerful language. It allows its users to ask what he\/she wants without disclosing any information on how the data will be recovered. However, the extensive use of SQL databases has attracted the attention of hackers. They take advantage of poorly coded web applications to attack databases. They introduce an apparent SQL query, via unauthorized user input, into the legitimate request statement. In this article, we have tried to present a complete review of all the different types of SQL injection attacks present, as well as the detection of such attacks and the preventive measures used. We highlighted their strengths and weaknesses. Such a classification would help other researchers to choose the right technique for further studies.<\/p>\n An effective approach to web security threats must, by definition, be proactive and defensive. Toward that end, this post is aimed at sparking a security mindset, hopefully injecting the reader with a healthy dose of paranoia.<\/p>\n In particular, this guide focuses on 10 common and significant web security pitfalls to be aware of, including recommendations on how they can be mitigated. The focus is on the\u00a0Top 10 Web Vulnerabilities<\/a>\u00a0identified by the\u00a0Open Web Application Security Project (OWASP)<\/a>, an international, non-profit organization whose goal is to improve software security across the globe.<\/p>\n From the biggest data breaches and cyber-attacks of the past decade, it is quite clear that marginal and careless mistakes and lapses in website security have turned out to be dangerous. Even big players have faced heavy losses, not just monetarily but in terms of customers, trust, brand image, and goodwill as a result of the attacks.<\/p>\n We have compiled the list of 10 most dangerous website security mistakes that you must avoid.<\/p>\n 1–SQL INJECTIONS (INJECTION FLAWS)<\/span><\/strong><\/p>\n 2- CROSS SITE SCRIPTING (XSS)<\/p>\n 3. BROKEN AUTHENTICATION & SESSION MANAGEMENT<\/p>\n 4. INSECURE DIRECT OBJECT REFERENCES<\/p>\n 5. SECURITY MISCONFIGURATION<\/p>\n 6. CROSS-SITE REQUEST FORGERY (CSRF)<\/p>\n 7- SENSITIVE DATA EXPOSER<\/p>\n 8- MISSING FUNCTION LEVEL ACCESS CONTROL<\/p>\n 9- USING COMPONENTS WITH KNOWN VULNERABILITIES<\/p>\n 10- Invalidated redirects and forwards<\/p>\n Don’t forget:<\/p>\n IRREGULAR OR NO WEBSITE SECURITY SCANS. <\/strong><\/span>The importance of regular website security scanning cannot be stressed enough. It is only through regular scanning that we can find vulnerabilities and gaps that exist, and accordingly, fix them. Organizations often make the cardinal error of not scanning their websites every day and after major changes to the business policies, systems, etc<\/p><\/blockquote>\n The OWASP Top 10 lists Injection and Cross-Site Scripting (XSS) as the most common security risks to web applications. Indeed, they go hand in hand because XSS attacks are contingent on a successful Injection attack. While this is the most obvious partnership, Injection is not just limited to enabling XSS.<\/p>\n The injection is an entire class of attacks that rely on injecting data into a web application to facilitate the execution or interpretation of malicious data unexpectedly. Examples of attacks within this class include Cross-Site Scripting (XSS), SQL Injection, Header Injection, Log Injection, and Full Path Disclosure. I\u2019m scratching the surface here.<\/p>\n This class of attacks is every programmer\u2019s bogeyman. They are the most common and successful attacks on the internet due to their numerous types, large attack surface, and the complexity sometimes needed to protect against them. All applications need data from somewhere to function. Cross-Site Scripting and UI Redress are, in particular, so common that I\u2019ve dedicated the next chapter to them and these are usually categorized separately from Injection Attacks as their class given their significance.<\/p>\n OWASP uses the following definition for Injection Attacks:<\/p>\n Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker\u2019s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.<\/p><\/blockquote>\n By the way, Injection flaws result from a classic failure to filter untrusted input. It can happen when you pass unfiltered data to the SQL server (SQL injection), to the browser (XSS \u2013 we\u2019 had been talked about this before<\/strong> <\/a>), to the LDAP server (LDAP injection), or anywhere else. The problem here is that the attacker can inject commands to these entities, resulting in loss of data and hijacking clients\u2019 browsers.<\/p>\n Anything that your application receives from untrusted sources must be filtered,<\/em> preferably according to a whitelist. You should almost never use a blacklist, as getting that right is very hard and usually easy to bypass. Antivirus software products typically provide stellar examples of failing blacklists. Pattern matching does not work.<\/p><\/blockquote>\n in the other definition,<\/p>\n SQL Injection operates by injecting data into a web application which is then used in SQL queries. The data usually comes from untrusted input such as a web form. However, it\u2019s also possible that the data comes from another source including the database itself.<\/p><\/blockquote>\n Programmers will often trust data from their database believing it to be completely safe without realizing that being safe for one particular usage does not mean it is safe for all other subsequent usages. Data from a database should be treated as untrusted unless proven otherwise, e.g. through validation processes.<\/p>\n If successful, an SQL Injection can manipulate the SQL query being targeted to perform a database operation not intended by the programmer.<\/p>\n Please consider the following query:<\/p>\n The above has several things wrong with it.<\/p>\n 1- First of all, we haven\u2019t validated the contents of the POST data to ensure it is a valid user_id.<\/p>\n 2- Secondly, we are allowing an untrusted source to tell us which user_id to use – an attacker could set any valid user_id they wanted to. Perhaps the user_id was contained in a hidden form field that we believed safe because the webform would not let it be edited (forgetting that attackers can submit anything).<\/p>\n 3- Thirdly, we have not escaped the user_id or passed it to the query as a bound parameter which also allows the attacker to inject arbitrary strings that can manipulate the SQL query given we failed to validate it in the first place.<\/p>\n The above three failings are remarkably common in web applications.<\/p>\n With user input channels being the main vector for SQL injection attacks, most of the defensive methods involve controlling and vetting user input for attack patterns.<\/p>\n Here are several measures that can ensure user input safety.<\/p>\n The first rule of thumb about user input is \u201cdon\u2019t trust and verify<\/a>,\u201d which effectively means all forms of the user input should be considered malicious unless proved otherwise. This accounts not only for simple input boxes such as text areas and text boxes but for everything else as well \u2014 such as hidden inputs, query string parameters, cookies, and file uploads.<\/p>\n Just because the browser\u2019s user interface doesn\u2019t allow the user to manipulate an input, it doesn\u2019t mean that it can\u2019t be tampered with. Simple tools such as\u00a0Burp <\/a>Suite enable\u00a0users to capture HTTP requests and modify anything, including hidden form values, before submitting them to the server. And if you think yourself clever by Base64 encoding your data, it can easily be decoded, modified and re-encoded by malicious users.<\/p>\n Validation is the process of making sure the right type of input is provided by users and to neutralize any potential malicious commands that might be embedded in the input string. For instance, in PHP, you can use the mysql\\_real\\_escape\\_string()<\/span>\u00a0to escape characters that might change the nature of the SQL command.<\/p>\n An altered version of the previously-mentioned login code would be as follows:<\/p>\n This simple modification would protect your code against the attack that was presented by adding an escape character (\\) in front of the single quotes that were intentionally added by the malicious user.<\/p>\n A note on validation:<\/strong><\/p>\n \u00a0If you\u2019ve added client-side validation functions, well done. But don\u2019t rely on it as a defensive measure against SQL injection attacks. While client-side functions might make it a notch harder to send malicious input to your server, it can easily be circumvented with a few browser tweaks and tools such as the one just mentioned. Therefore, you need to complement it with server-side validation.<\/p><\/blockquote>\n Some programming platforms, such as #ASP.NET, include built-in features that will automatically evaluate user input for malicious content on page postbacks. But they can be circumvented by hackers with enough nerves and subtlety, so you should nonetheless run user input through your security check procedures. You can never be too cautious.<\/p>\n A better alternative to escaping would be to use command parameters. Command parameters are defined by adding placeholder names in SQL commands, which will later be replaced by user input. ASP.NET has a very intuitive and easy-to-use set of APIs for this purpose.<\/p>\n The following code, written in C#, shows how you can use the command parameters to protect your website against SQL injection:<\/p>\n Report Advertisement<\/strong><\/span><\/p>\n <\/p>\n you start by creating a You then create instances of\u00a0 Finally, you add the\u00a0 In PHP, the equivalent is prepared statements, which is a bit more involved than its ASP.net counterpart. You can explore it\u00a0here<\/a>.<\/p>\n This tip is for languages such as PHP, which are weakly typed, which means you do not usually define data types for variables, and the language automatically takes care of converting different data types between each other.<\/p>\n Explicit casts can act as a shortcut to escaping input where non-string types are involved. So, if you\u2019re expecting the user to input an\u00a0 Take note that this snippet only validates the input\u2019s type, not its range. So you\u2019ll have to run other code to make sure the user doesn\u2019t enter a negative age \u2014 or an unrealistic one such as 1300.<\/p>\n Also, another best practice is to avoid using single quotes in SQL commands where non-string input is involved. So instead of using the following code \u2026<\/p>\n \u2026 it would be a bit safer to use the following one:<\/p>\n The good news is that protecting against injection is \u201csimply\u201d a matter of filtering your input properly and thinking about whether an input can be trusted. But the bad news is that\u00a0all<\/em> input needs to be properly filtered unless it can unquestionably be trusted (but the saying \u201cnever say never\u201d does come to mind here).<\/p>\n In a system with 1,000 inputs, for example, successfully filtering 999 of them is not sufficient, as this still leaves one field that can serve as the Achilles heal to bring down your system. And you might think that putting an SQL query result into another query is a good idea, as the database is trusted, but if the perimeter is not, the input comes indirectly from guys with malintent. This is called\u00a0Second Order SQL Injection<\/a>\u00a0in case you\u2019re interested.<\/p>\n Since filtering is pretty hard to do right (like crypto), what I usually advise is to rely on your framework\u2019s filtering functions: they are proven to work and are thoroughly scrutinized. If you do not use frameworks, you need to think hard about whether\u00a0not<\/em>\u00a0using them makes sense in your server security context. 99% of the time it does not.<\/p>\n in the other word, SQL injection has been around for decades and will likely continue to top the vulnerability charts for years to come. It takes a few easy \u2014 but well-calculated \u2014 steps to protect yourself and your users against it, and it should be among your top priorities when auditing your source code for security holes.<\/p>\n The key to avoiding being the victim of the next huge SQL injection data breach is first, to control and validate user input, and second, to prepare yourself for the \u201cwhen,\u201d not the \u201cif.\u201d<\/p>\nSECURITY IS THE MAIN PARMAMETRE<\/h2>\n
MOST COMMON WEBSITE SECURITY VULNERABILITIES<\/h3>\n
What is SQL Injection Attacks<\/h3>\n
$db = new mysqli('localhost', 'username', 'password', 'storedb');\r\n\r\n$result = $db->query(\r\n\r\n'SELECT * FROM transactions WHERE user_id = ' . $_POST['user_id']\r\n\r\n);<\/pre>\nHow to Protect Yourself Against SQL Injection Attacks<\/h2>\n
1-Never trust user input<\/h3>\n
2-Validate input strings on the server-side<\/h3>\n
$con=mysqli_connect(\"localhost\",\"user\",\"password\",\"db\");\r\n\r\n$username = mysqli_real_escape_string($con, $_POST['username']);\r\n\r\n$password = mysqli_real_escape_string($con, $_POST['password']);\r\n\r\n$sql_command = \"select * from users where username = '\" . $username; $sql_command .= \"' AND password = '\" . $password . \"'\";<\/pre>\n
3-Use command parameters<\/h3>\n
SqlCommand cmd = new SqlCommand (\"SELECT * FROM users WHERE username=@username AND password=@password\",con);\r\n\r\nSqlParameter username = new SqlParameter(); username.ParameterName = \"@username\"; username.value = txtUsername.Text; cmd.Parameters.Add(username);\r\n\r\nSqlParameter password = new SqlParameter(); password.ParameterName = \"@password\"; password.value = txtPassword.Text; cmd.Parameters.Add(password);<\/pre>\n
SqlCommand<\/code>\u00a0object and using the\u00a0@parameter_namethe <\/code>paradigm in the command string where user input should be inserted.<\/p>\nSqlParameter<\/code>\u00a0objects, in which you insert the user input, instead of directly concatenating it with the command string.<\/p>\nSqlParameter<\/code>\u00a0object to the\u00a0SqlCommand<\/code>\u00a0object\u2019s Parameters collection, which will replace the parameters with the provided input. ADO.net takes care of the rest.<\/p>\n4-Explicitly cast your input<\/h3>\n
int<\/code>\u00a0for the\u00a0age<\/code>\u00a0parameter, you can ensure the safety of the input with the following code in PHP:<\/p>\n$age = (int)$_POST['age']; \r\n<\/code><\/pre>\n$sql_command = \"select * from users where age = \" . $age; \r\n<\/code><\/pre>\n$sql_command = \"select * from users where age = '\" . $age . \"'\"; <\/code><\/pre>\nConclusion:\u00a0<\/strong><\/h2>\n