As a web developer, you and your clients’ websites all fall under your management when developing and maintaining all aspects of the website. In other words, it’s your responsibility to design an attractive, user-friendly, and secure website. Between trends, advice, and shortcuts, the aesthetics and UX of a website has been covered extensively. The security, however, should be so crucial to you and your clients because without security, all that you’ve worked for and built can be destroyed, stolen, or (worst yet) changed.
After the popular Target hack incident, many webmasters have opened their eyes and began looking at the security of their own websites. Here’s a surprising statistic: In 2012, about 86% of all websites had at least one vulnerability. Only 61% of those were patched, and the average time until the issue was resolved was over 6 months.
How secure is your website? What can you do to prevent hackers from waltzing in?
Website Changes
We’ve all been stuck at the debugging process before searching for hours on end to find that one mistake in the code. It’s annoying and takes up way too much time, but it has to be done. When a hacker breaks into a website, they are generally after something, with money and identities topping the target list. On the way out, they don’t leave everything the way it was. No, they will make your life as difficult as possible to get the website back in good condition. So they change stuff, starting with the login. Once you realize all of the changes throughout the website, it may even be worth starting over from a backup and working from there because finding a change as opposed to something missing is like finding a needle in a haystack.Avoiding All of this Altogether
It’s safe to say you’d rather not deal with any of what’s associated with a website break-in. So, here come the website security basics that every web developer must implement to have a secure website. Some of the topics we’ll discuss include:- Securing Logins
- SQL Injections
- Open-source Vulnerabilities
- Cross-site Scripting (XSS)
- Spam Filters
- SSL/Credit Card Security
Securing Logins (Don’t skip this one!)
You’ve heard this before: “you need a secure password.” Well, let’s jump slightly further into that. Your administrative logins are the keys to your website. Protecting them should be your priority as a web developer, designer, webmaster, or owner. So the first thing is to not give out administrative logins like candy. Lock down the heart of your website and only give the access to those that need it.As we all already know, there are two fields to a login: the username and the password. Many web developers assume if the password is secure, they’re fine. When someone recommends you change the default login, they don’t mean change the default password. They said the “login”, meaning both the username and password. I highly recommend changing the username and password to something you can remember but is secure, meaning upper-case, lower-case, numbers, and symbols. Both fields are just as important because if a hacker has just one and not the other, they can’t get in. Don’t ignore your username, and please don’t use the username “admin.” It’s the first username any novice hacker would try.
SQL Injections
If your website uses an SQL (Server Query Language) database (pretty likely), you are vulnerable to SQL injections. Before diving any further, do not think SQL databases are unsecure because, in most cases, they are very secure. The process when using an SQL database for logins consists of:- User input (username, password)
- Sending of information to the SQL database
- The SQL database checks the data with current information
- Data is found to be true or false
- Results are returned to the user. If one of the fields comes out false, the login fails. If both are true the login succeeds.
Here’s an example in English: “Yes or no: Are you a human OR dead?” Technically, yes, because you’re a human. The “OR” signifies you only need to meet one requirement, similar to the “If…Else” statements in web coding and scripting.
Extremely poor-coded SQL databases (very rare today) can even be told to dump the table in their response using complicated SQL coding. Oftentimes in multiple “login attempts.”
To prevent SQL injections, the best thing you can do is to use a set of rules where the user’s input is checked for syntax, length, and type. For more information on SQL injections (and a more in-depth look), take a look at Veracode’s article on SQL injections.
0 komentar:
Posting Komentar