Every year, OWASP (the Open Web Application Security Project) releases a lengthy report on the top server and application security risks commonly found online. We’ve reduced that lengthy report down to a list of 10 easy-to-understand security vulnerabilities facing site owners and web developers.
Look over this list, and ask yourself if your site is truly secure. (Hint: If you’re relying on CMS “security” plugins, then you’re not secure!)
1. SQL Injection Attacks
An SQL injection is where hackers exploit code in a web application in order to gain access to the database. The exploit is usually accomplished by merely tweaking the URL to include malicious commands.
Hackers can then deface the site, steal information, alter information, or all of the above.
SQL injection can sometimes lead to an entire server being compromised, not just a single database.
How to prevent SQL injection attacks
Parameterized API for data access
The most effective solution to resist an attempted SQL-injection is to make use of a safe API that employs a parameterized interface. SQL parameters are values that are added to an SQL query in a controlled manner at the time of execution. APIs can be designed carefully to avoid special characters and expressions that can be used to inject malicious commands.
There is no way to inject custom SQL statements over Parameterised Queries. When you take away the ability for hackers to use delimiter characters such as the single quote (‘) or the double quote (“), your risk of SQL injection disappears.
Firewall (WAF)
A web application firewall can validate an URL before it’s executed. A good WAF will maintain an internal database of known exploits, and exploit fingerprints, and block the malicious user.
Convert to HTML
Although a CMS like WordPress is popular, it can be the wrong choice for a small business. While WordPress is the #1 most popular CMS, it’s also the #1 most hacked codebase on the web. HTML sites aren’t dynamic, and non-dynamic (non-database) sites are immune to injections.
Google dorking
(No, these aren’t the dorks that got beat up in high school!) Google dorking, aka Google hacking, is where you use Google searches to locate both potential vulnerabilities and already-exploited code.
Hackers already use it to find flawed code. For example, a hacker can search for something like “in payment.php?CartID=“ and then test to see if there’s a vulnerability.
Search your own domain for sensitive information, or strings in your CMS that you are worried might not be secure.
Here are a few more things you can dork:
- inurl:cgi-bin ext:pl intext:”-rwxr-xr-x”
- allinurl:wp-content/plugins/wptf-image-gallery/
- site:mysite.com viagra
- site:mysite.com filetype:xls
We will not support the enemy by linking to them, but if you want to seriously give yourself a good Dorking, a quick search on Google will give you tons of results for hacking websites showing off their favourite Dorking queries.
Robots.txt
Although it’s security by obscurity, Google dorking can be blocked using your robots.txt. And although it means that you’ll be blocked from dorking, so will the hackers and script kiddies.
.htaccess (Apache) or the nginx .conf
Using .htaccess or the nginx configuration file, you can restrict sections of your website from being crawled by bots.
Again, security by obscurity.
2. Broken authentication, poor session management
Broken authentication is essentially digital identity theft, allowing an attacker to impersonate your identity on the server. It can have many repercussions, from simple defacing a website to gaining complete control of a server.
Web applications use session tokens to communicate with a user. But it the tokens are not properly protected, the active session can be hijacked.
The most common reasons of hijacked sessions:
- Credentials stored in plain text.
- Credentials are weak, and can be guessed.
- Session IDs are exposed in the URL
- Session IDs are vulnerable to session fixation attacks
- Session IDs do not timeout
- Session IDs do not expire, and are not rotated
- Credentials and session IDs are sent over unencrypted connections (allowing man in middle exploit)
But preventing this problem is fairly easy:
- Use reliable SSL Certificates like Comodo SSL Certificate, RapidSSL Certificate, GeoTrust SSL Certificate, Thawte SSL certificate, DigiCert SSL Certificate etc..
- Encrypt credentials when stored on the server, using hashing, MD5, etc.
- Enforce strict cookie control, to thwart impersonating tokens
- Pay attention! Audit records regularly, and proactively monitor for updates and patches to servers, scripts, software and applications.
3. Cross Site Scripting (XSS)
XSS doesn’t target a server, but the browser (the person and the software). It’s a client-side attack. The hacker injects malicious code to gain control of sensitive page content, user sessions, or the web browser itself.
Originally a JavaScript exploit method, it now includes any attack that attempts to maliciously redirect traffic to a bad site. JS, ActiveX, VBScript, Flash, cookies, and even HTML and CSS can deliver XSS payloads.
XSS relies on brute force to hijack sessions and redirects them to malicious sites.
It can bypass access control policies (ACL) to elevate the attacker’s permissions – up to and including administrative access. It can also grab crucial information about a web server and user accounts.
Any web environment can be exploited by XSS:
- web applications
- servers
- scripts
- plugins
… As was the case with SQL injections, there have been were several high-profile hacks in recent years:
Recent Cross Site Scripting (XSS) Attack Victims
All social media sites have so far been a victim: Facebook, Twitter, and Youtube.
IBM Domino Lotus Notes, a platform for hosting social business applications, was hit. A hacker exploited a vulnerability and gained access to sensitive business information and communication.
| How to protect a server from XSS vulnerabilities: | |
| Vulnerability scanning | Like anti-virus or anti-rootkit software, these crawl a server, looking for threat surfaces. |
| Retrospective attack simulation | You essentially try to attack your own server, and see if you can break in. And if so, it’s time to start addressing the findings. |
| Escaping code | A web browser can be forced to treat certain strings of code as plain text. So even if a hacker managed to insert a malicious executable on a site or application, client-side browsers interpret the data as plain text and not a script. |
In addition to employing vulnerability scanning and escaping techniques, there are a few other defensive mechanisms to prevent XSS attacks.
Content Security Policy, Javascript Sandbox Tools and Auto-escaping Templates are some of the effective control strategies that can be explored and implemented to achieve a secure web hosting environment. Looking to learn more about this? Check out AlgoMonster.
4. Insecure direct object references
This vulnerability is a result of insufficient authorization checks. Hackers can access resources on the server by modifying a parameter that points to an object on the server. For example, an unprotected JPEG file could easily cause a breach that grants the hacker admin access.
At least 7 of every 10 attacks of this nature occur due to non-implementation of proper access control schemes. Essentially, it’s just bad website or application development at fault.
A simple image file or a harmless directory structure can potentially be transformed into a threat surface to steal confidential data from a server system.
| How to protect against insecure direct object references: | |
| Tiered Access Control |
An unprotected internal object can be used to break through an otherwise secure web environment. Hence, it’s vital to incorporate a role-based tiered access restriction process, in line with the principle of ‘least privilege,’ to mitigate this vulnerability. |
|
Randomly generated parameter postfix |
Instead of using a symmetric or sequential format (object ID), you can make use of a randomly generated postfix parameter, which is appended to a file name, to refer to a particular web object. As soon as an attempted manipulation of the parameter value gets detected, the source IP address, from which the request originated, should immediately be blocked.
|
|
Protected folders, encrypted database keys |
OWASP advocates encryption of all data points and their references. Password protected folders and directory structures can be used to prevent unauthorized access to restricted content. Also, the database keys must be stored in encrypted file formats, so that only authorized users could access the database files. |
|
Powerful monitoring and analyzing tools |
Prevention is always better than a cure. You should consider implementing intuitive monitoring tools and log-data management services for proactively detecting vulnerabilities related to insecure object references. |
5. Cross-site request forgery (CSRF)
CSRF, also known as “1-click attack” or “session riding”, is a type of exploit where unauthorized actions are transmitted from a user’s browser to the attacked website without the user’s knowledge.
It attempts to forge an HTTP request on behalf of an authenticated user by inserting code to force an action. CSRF exploits how the target website manages authentication. The victim must be logged in to the target site at the time of the attack.
Riding on a legitimate user’s authenticated session, an attacker can use CSRF to launch any requests to the vulnerable website. The attacked website won’t be able to distinguish whether the requests were created by a legitimate user or not, so it will simply execute the command as directed by the attacker.
CSRF is similar to XSS. XSS exploits the trust a user has on a particular website, whereas CSRF exploits the trust that a website has in a legitimate user. CSRF is often implemented by using XSS. E-commerce and other transaction-based websites are most vulnerable to CSRF attacks.
While XSS is used to elevate an attacker’s access credential to steal vital information, it does not force the server to perform any action. In the case of CSRF, a command is transmitted to the server to perform some action on behalf of the logged in user.
Recent High-Profile CSRF Attack: Ebay
In 2015, e-commerce behemoth eBay was subjected to an attempted CSRF exploit. An attacker tried to make use of a reflected file download vulnerability on the eBay website to trick victims into downloading a malicious file.
Victims were unaware of the CSRF, and thought the download was an official eBay file. It could have resulted in serious security compromise if the attacker had intention to misuse this vulnerability. However, the attacker was an internet security researcher at WebSegura – much to the relief of eBay and its users.
| There are several ways to protect against CSRF: | |
| Implement session tokens | By generating a cryptographic session token at the time of user authentication, and postfixing the token in all requests raised by the user, the risk of CSRF can be mitigated substantially. In order to forge an HTTP request on behalf of a particular user, the attacker would have to know the value of his session token (which is very difficult to guess). |
| Terminating idle sessions | It’s vital that the user logs out from web application after finishing their activities. Otherwise, the server should be configured to disconnect all user sessions in idle state after a certain period of inactivity. It will prevent an attacker from launching a CSRF attack using the authenticated user’s session token. |
| CSRF vulnerability scanner | A competent scanning tool can crawl your website on a periodic basis, detect any CSRF vulnerabilities, and report it to you in a timely manner. |
6. Security Misconfigurations
These are user errors — i.e., not properly configuring sites and servers, thereby opening security holes.
Typical boneheaded actions include:
- Easy-to-guess passwords (password, 123456, iloveyou, etc)
- Using default Ids and privileges (admin, letmein)
- Disclosing debugging information (phpinfo)
Even vital infrastructure is not immune to (stupid) user error
In recent times, the U.S. power grid was at risk.
The government security ICS-CERT discovered the malware BlackEnergy exploiting multiple human-machines interface (HMI) products connected to the internet. And it happened because of a simple misconfiguration being exploited by bad actors.
Misconfigurations can occur at any level of an application stack:
- Platforms
- Web servers
- Application servers
- Databases
- Frameworks
- Custom modules.
Application developers and administrators must work closely to ensure that the entire stack is configured properly!
More often than not, security misconfigurations occur because of blind trust in default settings.
Attackers may target default accounts, unused pages, unprotected files, unsafe directories, or un-patched server flaws.
The default configuration may include:
- Unnecessary and unsafe features
- Known usernames and passwords
- Hard-coded backend admin accounts
- Special access mechanisms for the developers group
Typical misconfigurations include:
- Improper file and directory permissions.
- Unnecessary services in enabled state.
- Default accounts with their default passwords.
- Exposure of administrative or debugging notifications to general users.
- Misconfigured SSL certificates and encryption settings.
- Misconfiguration of user roles.
- Improper authentication with external systems.
Bridge the communication gap between developers and sysadmins!
The development team is usually not involved in the day-to-day operation of an application or website. System admins are usually tasked with that. But it may lead to a communication gap. It’s important to bridge this gap to ensure everyone is working as one single team to eliminate security vulnerabilities.
7. Sensitive Data Exposure
Business data can be categorized as public data or private/protected data. All businesses have some confidential data that must be safeguarded from appearing in the public domain.
Unauthorized data access often occurs due to a web application not properly protecting data. A lack of quality encryption and improper key generation is often at fault. Thankfully, this type of vulnerability is usually very difficult to exploit.
Example of Sensitive Data Exposure:
How do you ensure that your smartphone does not contain sensitive data before reselling it to someone else? The obvious answer is a “factory reset”, which supposedly wipes the phone memory and restore the settings to system default. However, if you are an Android user, then that’s not sufficient!
A Cambridge University team of researchers discovered some Android mobile devices have a flawed factory reset function, and the phone is incapable of fully erasing sensitive user records. A hacker could use a “wiped” Android phone to gain your passwords on social media, or even that old sext from an ex!
| There are several ways to prevent sensitive data exposure: | |
| Enforce strict data encryption | Implement a proven encryption technique. Make sure sensitive data is kept encrypted at all the times. Such data should neither be stored nor transmitted in clear text format. |
| Use SSL | Protect your website with the secure HTTPS (SSL/TLS) protocol. SSL uses a public/private key pair to transmit data. |
| Implement strong password hashing algorithm | Hackers can exploit the weakness in password hashing algorithm to steal sensitive information stored on a web or application server. Only cryptographic hash functions should be used to implement password hashing. |
| Use penetration testing | A third-party “pentest” will give you insight on how secure the application is. Even the best programmers are susceptible to occasional mistakes. So it makes sense for security expert to review the application for potential vulnerabilities. For best results, test it periodically, not just during an initial launch. |
8. Missing function-level access control
This vulnerability is caused by an incorrect configuration, or the server not verifying access rights.
Relying on security by hiding restricted functions does not work. An attacker can still unlock the restricted functions by simply guessing the probable parameter value. So you must enforce sufficient authorization to restrict general users from accessing privileged functions.
Example: the “/admin” folder for a website.
Simply hiding all links to the URL will not suffice. An attacker will simply guess all typical locations, and proceed to brute-force it once located.
| How to protect yourself from missing function-level access control: | |
| Use authentication mechanism | Ensure that only authenticated users have the privilege to view server resources. To use “public” functions, a user must still authenticate himself first. |
| Implement tiered-access control | In a web application with different user roles, authentication is not sufficient. Each request must be mapped against the user’s role to ensure that the user is authorized to access the requested resource. |
| Tiered access control | Consider creating group policies to distinguish between users, where each user group will have its own level of access permissions. It ensures that only the intended users are allowed to perform certain actions. You can also control access to protected resources by inserting applicable rules to a specific group of users. |
|
Avoid assigning per-user permissions |
Tiered access control provides access rights to a group of users belonging to the same level. All the users belonging to a particular group should have the same access level. If there’s a requirement to provide some enhanced privilege to a particular user, then you should create a different group, move the user to the new group and assign required permissions at the group level. |
| Deny access by default | In case of an undefined condition (a situation which has not been defined by the developers) with respect to user control, instruct the application to deny access by default. |
See table below to learn about the three types of access control strategies which are recommended for implementing full-proof function level access control.
| Three types of access control strategies: | |
| Vertical Access Control | To prevent standard users from accessing admin functionalities. |
| Horizontal Access Control | To prevent a user from accessing the private data of other users belonging to the same privilege level. |
| Business Login Access Control | To prevent the abuse of privileges linked with business objectives. |
9. Using components with known vulnerabilities
Hackers regularly scan with automated tools, looking for known-vulnerable entry points. Regularly patching and updating all components is vital to a sound security policy. Vulnerabilities in third-party software libraries, open-source technologies or frameworks are relatively common.
If a hacker manages to identify a vulnerable component that you are using, then your site, server, or application is at risk. Using external software is often unavailable, but it can also be an off-site exploit to break into your site or application.
| How to protect yourself: | |
| Identify external components, investigate security issues |
Identify external components and investigate security issues. Identify all open-source and third-party software libraries used for the project, including their version numbers and patch releases, if applicable. Research possible vulnerabilities linked to those components. In case of a previous security incident, perform a root cause analysis and find if there was a permanent resolution. |
| Monitor external components for possible future threats | Monitor all external components and keep yourself updated with every bit of relevant information throughout the life-cycle of your project. |
| White-listing external destinations (URLs) | While it may not always be possible to completely avoid user inputs for redirects and forwards, you must ensure that no unvalidated data is being used for this purpose. If user inputs can not be avoided, then you can sanitise inputs by maintaining a list of trusted URLs. |
| Implement security policy | Define security policies to govern the usage of third-party components, and conduct vulnerability tests to assess their preparedness. Make sure that all the components pass through the defined security tests and guidelines before incorporating them in your project. |
| Disable unused features and functions | To restrict the threat surface area, always disable the functionalities that you do not require. |
10. Unvalidated Redirects and Forwards
All modern websites use URL redirects. While configuring a redirect, the destination page is specified as a parameter in the address bar. When an application uses an untrusted parameter to redirect a user without validating the credibility of the destination page, an attacker can use the redirection parameter to launch a cross-site scripting or drive-by download attack.
Having users click a malicious link is the most common use of this vulnerability. Hackers may attempt to install malware on the victim’s computer or trick the victim into disclosing passwords or other sensitive information. It can also be used to bypass access control.
| How to protect against unvalidated redirects and forwards: | |
| Don’t use redirects | The most obvious mitigation strategy is to avoid redirects and forwards. If you do not use redirects, then you can never be vulnerable to this form of security threats. |
| Disallow redirect parameter from accepting user input | If you have to use redirects, then it should be done without involving user parameters in redirecting the destination. Do not allow any user input for determining the destination page. |
| White-listing external destinations (URLs) | While it may not always be possible to completely avoid user inputs for redirects and forwards, you must ensure that no unvalidated data is being used for this purpose. If user inputs can not be avoided, then you can sanitise inputs by maintaining a list of trusted URLs. |
| Create a white-list of trustworthy external websites to which redirects and forwards can be allowed. | Compare user input values to the white-list entries and ensure that the destination parameter value supplied by the user is requesting redirect to a valid external website. Any attempted redirection to other external pages must be blocked by the server. |
| Avoid using URLs as redirection parameter | Instead of using the actual URL as the destination parameter, it is highly recommended to employ a mapping value to identify the destination URL. Server side code can be used to translate the mapping value to the destination URL at the time of execution. |
| Force user notification on redirects and forwards | Force all redirects and forwards to first go through an interface notifying the users that they are leaving your website or application and going to an external website. You can have a validation check at the interface where the users will have option to either go to the external page or return safely to the previous page. |
Want secure sites? Contact EuroVPS!
As a managed hosting provider, our job is to make sure that our customers are secure. This includes secure from SQL injections, XSS, and everything else mentioned in this top 10 list of vulnerabilities and exploits.
So when it’s time to setup that fresh VPS or bare-metal server to host your precious websites and applications, start on the right foot.
Get an experienced managed host that knows security.
We also offer professional services that include vulnerability scanning and penetration testing, security audits, and more. These can drastically reduce the chance of falling victim to attacks by hackers. Our veteran security specialists have extensive experience and can help you identify vulnerabilities before they evolve into full-blown exploits.
All open-source frameworks and software libraries at EuroVPS are subjected to thorough security checks. Meeting the “acceptable usage guidelines” is a mandatory prerequisite for third-party packages before they are made available to EuroVPS customers.
