*

Development Principle 6: How to avoid common code vulnerabilities?

21 Apr. 22
332 VIEWS

Hackers are experts at finding vulnerabilities in your website and exploiting them to their advantage. Hackers may attempt to exploit vulnerabilities for a number of reasons, such as data theft, the defacement of websites, or political or social motives often tied to activist movements. Regardless, knowing how to protect your website from the ground up is critical to protecting your website. Today, we’ll explain some of the common attack methods hackers utilize to get into your website.

SQL Injection

 

Problem

 

Your application’s connection with the database is one of the oldest vulnerabilities, and the most prevalent today. It can be tempting to create an AdHoc SQLQuery when you are coding quickly. This allows you to simply add your query parameters to a SQL statement.

 

[code]”SELECT * From [MyTable] WHERE “name” = ‘” + myQueryName + ” ORDER BY DESC code]

[code]”SELECT * From [MyTable] WHERE “name” = ‘foo; SELECT user from [users] WHERE “1 = 1’ ORDERED BY [created_at] DESC code

This could lead to a situation similar to the famous ” Bobby tables” comic.

Solution

 

When creating your SQL query, the most common approach is to use a parameterized query. This is a feature of all mainstream languages that can “talk” to a database. This involves setting up your query using variable placeholders. The managing code will then convert any system characters into their “plaintext” counterpart. This cheat sheet contains examples for many of today’s most common languages. 

An alternative solution is to use an Object Relational Model library (ORM) to manage your data access. Entity Framework, ActiveRecord and Eloquent are all popular ORMs. They make it easy to quickly and easily scaffold your code against the back-end database for all your Create Retrieve, Update, Delete (CRUD), operations. Parameterized queries are used by these ORMs, so you don’t have to do any additional work once the scaffold has been established.

XSS

 

Problem

 

Cross-Site Scripting attacks (XSS), which are similar to SQL Injection, occur at the browser level. Instead of using fake data to attack the database, the bogus information is stored in the database with the intent to infect others who visit your site. If you fill out your user profile and put ” in front of your first name, then the page rendering the site’s users list could send an alert message to everyone who views the site. You could accidentally redirect the user to malicious sites if you modify the script. This attack is sophisticated and will infect fully-running scripts behind a value to hide it from the user or the code owner.

Solution

 

This is why it is common to clean your data at the client level before you insert it into the database. This usually involves replacing any closed brackets or open/closed brackets. These attacks can be prevented by removing keywords such as “script” and events (such “onmouseover”, “onclick”), if necessary. This task can be accomplished by a variety of libraries, both client- and server-side.

You should remember to both sanitize the data coming into your database and clean it up afterwards. Even though you are sanitizing input properly before submission, it is possible that your database was hacked and your data modified using a different vector (API or direct login). You could expose your users to risk. This can be done by cleaning up your data before it is displayed on the page. While browsers are becoming more sophisticated in protecting users against XSS attacks, it is important to keep your data safe.

Keeping Sensitive Information in Cloud Source Control

 

Problem

 

Online code repositories, continuous integration and continuous integration have become more popular. While this is good to develop communities around programming and projects, it has also led to an increase in stolen resources and credentials from hackers. This is because many continuous integration solutions need login credentials or database credentials to work correctly. These credentials can be used to access your code repository online, or worse, hack it. They could also be used to exploit API keys and other sensitive information.

Solution

 

It is best to avoid using public cloud repositories to store your code. Many providers like Bitbucket or GitHub offer private repositories that lock your files over a secure connection. They are not visible unless the user is logged in and has privileges to them. This prevents hackers from stealing your credentials.

It is best to not include sensitive information in any code. Many cloud hosting platforms, including AWS and Azure, allow you to store sensitive information inside the container. Then, you can inject it into the correct configuration file. These cloud hosting platforms follow the same configuration patterns so only minor code changes are required to make this work. Continuous integration solutions can now connect to remote repositories via OAuth or SSH key connections. This eliminates the need for login credentials. These tokens/keys can only be used for the original source requested.

Code Safer

 

While it may require extra work to ensure your code does not fall into these common pitfalls, the security they offer will help keep your website stable and protected for much longer. Get out there and start coding!

We use cookies to give you tailored experiences on our website. Talk to us for COVID19 Support
Okay