How hackers check to see if your website is hackable

“Memento mori” is Latin for “Remember that you are mortal.” According to tradition, this phrase was whispered to triumphant Roman military commanders on parades, to remind them they remained fallible humans. 

In these times, perhaps the tradition should be updated to whispering “you will be hacked” into the ears of website administrators. This may be necessary to remind them that no matter what defenses they have deployed, hackers are always looking for new ways to hack sites. 

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

But what are the methods that hackers use? Below, we look more closely at how website hackers may target client-side, server-side or direct vulnerabilities.

Server-side vulnerabilities

Aside from phishing and related attacks on administrators, hackers will frequently attempt to determine the webserver type (e.g., Tomcat), web server software (e.g., node.js) and server operating system. This may be achieved by examining factors such as general intelligence (e.g., from comments on social media and tech sites), session cookie names, web page source code and more.

Once the backend technology has been determined, hackers can use a variety of methods to exploit unpatched vulnerabilities. Insecure server setup, such as insecure server default configurations, unrestricted access to server folders and open ports have all been exploited to hack sites.

Insecure default server configurations are often tested by hackers, such as leaving default credentials active. Scanning tools such as Grayhat Warfare are often used by hackers to find insecurely configured Amazon S3 bucket contents.

Open ports are easy for hackers to pick up using port scanning tools, and once detected, a variety of vulnerabilities may be exploited.

Similarly, tools to scan for files may find administrative tools that can be accessed with weak passwords — or no passwords at all. Inadequate restrictions on file uploading to server folders is also a gift to hackers, allowing them to upload and execute malware.

Client-side vulnerabilities

On the client-side, common vulnerabilities include:

• SQL injection: Inserting SQL commands into requests, resulting in unauthorized release of data or modification of database entries
• XSS: Injection of malicious code
• CSRF: Taking over a user’s session

The OWASP Top Ten Web Application Project found that injection attacks were the number-one threat type.

Hackers have at their disposal readily available tools to automatically test sites for these vulnerabilities, in the same way that legitimate pentesting is performed. These days, however, it would be very surprising and negligent for a website to have insufficient protection against SQL injection and CSRF attacks. XSS, however, continues to pose threats as new vulnerabilities come to light, especially as web pages (including those embedded in mobile apps) become more feature-rich and complex. Once a vulnerability is found, it can be exploited quickly across sites that have not patched it out.

Frameworks and cyberthreats

Contemporary web development practice, with its heavy reliance on open-source libraries, plugins and frameworks, is a rich source of vulnerabilities that hackers can utilize. Hackers will put far greater efforts into examining libraries for vulnerabilities than the typical web developer ever will, and these flaws often surface only after they have been used for successful hacks. 

The rise of server-side JavaScript, and the increasing complexity of libraries and frameworks means that these types of exploits are increasing. This is often the case for open-source code that has had its development abandoned; this means that no updates are available, and vulnerabilities are left exposed for sites that continue to use them.

APIs and cyberthreats

Websites that use APIs to communicate with backend systems may have the APIs targeted by hackers. In this case, hackers will look for poor API security, such as credentials or access codes or tokens accessible from query strings, variables and other sources. 

Hackers will also try to gain information about the internal architecture of an API-based system by deliberately calling the APIs with invalid parameters and seeing if the resulting error messages leak information about the system. This information could be almost anything, such as database type and configuration. All of these snippets of information may be useful later, as new vulnerabilities emerge.

Direct cyberattacks and token attacks

As well as general hacking attempts on the client and server-side systems, direct attacks on user and administrator accounts are common. Hackers are currently focusing on using credential (password) stuffing more than brute-force attacks on username + password authentication, as well as attempts to manipulate or reuse access tokens.

With 61 billion credential-stuffing attempts in the 18 months to June 2019, this attack method is proving popular. Credential stuffing involves automated login attempts using usernames (or email addresses) and passwords harvested from server-side breaches to attempt to gain access to user or administrator accounts.

Often issued via OAuth2 or OpenID Connect (OIDC) protocols, access tokens are necessary in today's web environment, authorizing requests to resources such as user account data, APIs and other resources. This ubiquity affords another prime target for hackers — as we have seen, for example, in the Facebook breach of 2018.

These tokens are most commonly in the form of JSON web tokens (JWT). Hackers will look for vulnerabilities such as XSS that enable tokens to be stolen from cookies, local storage and JavaScript variables. Because the majority of these tokens are of the bearer type, it is trivial for them to be used by the hacker once stolen, at least until they expire.

Similarly, hackers will also attempt to exploit insecure handling of token signatures, so that they can change token access rights, expiration times and so on without invalidating the signature. One simple method hackers try is changing the signature algorithm value stored in the JWT header to “none.” In an insecure implementation, the signature checking code will then ignore the token signature, meaning that changes to the token content will be missed.

A final thought

Modern web development and phishing tactics have opened up the attack surface so much so that websites and web applications are highly vulnerable across myriad points of entry.

But one final thought: like squirrels, hackers don’t think like you and have no boundaries in what they will try. If their attempts crash a site or destroy a database that’s not a problem for them. When you think you have tested your site for vulnerabilities, you still need to be careful.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Sources

• Public buckets by grayhatwarfare, Grayhat Warfare
• OWASP Top Ten, OWASP
• State of the Internet/Security: Media Under Assault, Akamai
• What Facebook’s Hack Can Teach about Token Theft, WhiteHat Security