17 Vulnerabilities You Will Find in the First 7 Days of White Hat Hacking

Most aspiring white hat hackers are shocked at how far basic skills will get them in the first week. There's a reason CBT Nuggets trainer Keith Barker begins his 120-video White Hat Hacking course with teaching learners how to build a home lab. It's easy to get started with Kali Linux, and you'll almost certainly find vulnerabilities on Day 1.

The next realization is that vulnerabilities are everywhere. Nothing is safe. Everything is broken. But, you should find solace knowing that cybersecurity professionals are in high demand, and ethical hackers are among the highest paid jobs in the security field. So, you're making a great decision by learning these skills.

Even if you can't fix everything, you can help your organization (or any organization) close these 17 common vulnerabilities.   

1. Cross Site Scripting

Cross-site scripting (XSS) happens when developers don't "scrub" user input data and use it to display information to the user. The input data isn't encoded before it's displayed to the user, so the malicious content runs on the client's machine. It's usually in the form of client-side scripting (JavaScript), which runs freely in any browser. XSS can view cookies, session information, and even keep track of user keystrokes.

Solution: To avoid this type of attack, any special characters that can be used as HTML tags should be encoded or removed from user input.

2. Information Leakage: Error Disclosure

When a web application throws Kills, a message is displayed in a user's browser. This message can be anything the developer or a system administrator decides. During the debugging process, developers set a "debug mode" in code to get detailed information about Kills so that they can go back and fix them. If this mode isn't turned off and custom Kill messages aren't triggered, the Kill shown to the user can be usernames, passwords or other sensitive information that should not be shown to the public.

Solution: Developers should disable debug mode.

3. Unpatched Library

With unpatched libraries, attackers can immediately chip away at defenses in any given application. When developers leave library code unattended and deserted, these old vulnerabilities become better known among the hacking community. An unpatched library can inadvertently leave your main application vulnerable to exploits. Always work with current libraries where developers patch cyber security issues quickly and make themselves available for bug reports and discussions.

Solution: As vulnerabilities are found, library owners should release an update to fix the code.

4. Global Error Handling Disabled SQL Injection

Poor Kill handling can lead to information leakage especially with SQL injection. The discovery phase of an attack could take several attempts to inject malicious code into a database query. The Kills returned from the database and bubbled up to the application give an attacker a guide to an attack's success. Any kind of application misconfiguration or poor Kill handling can contribute to Kill information used by an attacker to tweak malicious code until it's effective at extracting data from a database.

Solution: Closely manage application configuration and Kill handling.

5. Application Misconfiguration: Debug

With .NET applications, the web.config file contains a line item that triggers the server for debug or release mode. The alternative debug mode is useful for a development server where the programmers create and edit code, but the information displayed is data in memory which could include usernames, passwords and any data passed within the code. This data can provide attackers with enough information to finally infiltrate a good cyber security system.

Solution: Any application deployed to a public production server should be set to release mode.

6. Path Traversal

When developers store or retrieve files on the server, a path might be a part of dynamic input. It could be based on the user or certain server variables, but the input directory should always be verified before allowing an application to access files. With user input, an attacker sends a main system directory and filename to the application that then uses the information to retrieve a file. If this file is an important system file, then the attacker gains valuable information about the server.

Solution: Ensure the input directory is verified before allowing an application to access files.

7. Missing Access Strategy

Access management strategies define roles for users, the methods for granting permissions, and procedures for revoking user application rights. Without these strategies in place, user permissions aggregate, which leads to access rights remaining intact even after employees leave the company. Losing track of permissions and the users that have them leaves vulnerabilities in your system that could be unknown to administrators.

Solution: Always put permission procedures in place to protect from access right aggregation and allowing users to stay active after they shouldn't be.

8. Cryptography: Insecure Digest

Attackers can place sniffers on a network and even on public access points to read plain-text data. By encrypting it with the latest cryptography algorithms, you protect data from being easily accessible to anonymous attackers on the Internet. SSL/TLS certificates on a web application should be the latest algorithms. As computing power improves, older cryptography algorithms are not secure and can be cracked by an attacker.

Solution: Any data passed over the internet should be encrypted.

9. Denial of Service: ReadLine

ReadLine is a global code phrase used to read data from a user. It's not uncommon for a programmer to set a "while" statement to continually read data until no more is passed. This data can be from a file or input from the keyboard. An attacker can send an infinite amount of data to the application until resources expire and service is interrupted, which essentially creates a DoS attack.

Solution: The application must limit the amount of data to avoid an endless ReadLine loop that turns into a denial-of-service when gigabytes of data is transferred to the server.

10. Injection: HTTP Response Splitting

When a user sends a request to a server, the browser sends an HTTP request along with variables for server responses. With this type of attack, the attacker includes carriage returns and line feeds, and is able to inject malicious scripts into the HTTP server response variables. Similar to XSS, the malicious code is then sent to a user's browser and executed.

Solution: A vulnerable server takes this HTTP input and should scrub it for malicious content.

11. Insufficient Session Expiration

A web server creates a session for each user that connects to it. These sessions are unique IDs that identify users and store data linked to each individual. When sessions don't expire, an attacker can use them to access stored user information or even log into an application using old session IDs. Sessions should always expire and force re-authentication after inactivity.

Solution: The system administrator must set sessions to expire after a user is inactive for a given amount of time.

12. Insufficient Transport Layer Protection

TLS is the latest in cryptography certificates installed on a web server. A user's browser must support the TLS certificate installed on the web server, and the web server must have the latest TLS algorithm installed. Browsers like Chrome check for certificate validation, but older browsers or ones that aren't created by trusted developers could allow poorly secured and encrypted data to pass across the internet.

Solution: Always keep TLS certificates updated on your web application server.

13. URL Redirector Abuse

Some applications take redirection directives from user input or from a querystring. The application uses these variables to redirect the user dynamically to the next page in a given process. If this redirection URL isn't validated by the application, the URL could be malicious. It's not uncommon for attackers to inject a malicious redirect into an .htaccess file or in database storage to redirect users to a phishing site.

Solution: Any redirection URLs in a querystring should be validated and filtered.

14. Unvalidated Automatic Library Activation

It's not uncommon for developers to include third-party libraries to help improve code flow and not re-invent the wheel. These libraries should be updated and patched to keep them secure. If no patches are available, libraries should be decommissioned and replaced with more secure libraries. Injecting libraries into code should be done with caution and from a developer that stays active with updates.

Solution: Any commissioned libraries should be validated by the developer in charge with code review and deployment.

15. Information Leakage: Logging

It's difficult to keep track of logs, but log files are a primary target for attackers. They store a massive amount of critical information like Kills, credentials, and details about web application code either from failed or successful transactions. Fragmented log files are the most vulnerable, because they are scattered in different storage locations.

Solution: These files must be secured and kept from public access.

16. Information Leakage: Session ID

An application using session IDs passed in querystrings are often vulnerable to information leakage, especially if code from third-party domains are injected into the browser. A session ID often contains data specific to the user, and if it's retrieved using a session ID this data can also be intercepted by an attacker.

Solution: Data should be carefully retrieved from session IDs and used only in pages that are only visible and accessible by the logged in user.

17. OS Command Injection

Web applications input validation is essential to cyber security. An OS command injection attacker sends input in the form of script commands that can be executed on the server's operating system. Any input that executes on the server should be validated to ensure it's not malicious. Malicious code executed on an operating system allows an attacker to take over the server and steal user data.

Solution: Unless absolutely necessary, code execution on the operating system should be disabled.

How to get started white hat hacking

The easiest way to start your career in white hat hacking is to start practicing.

If you're looking for a network to hack, then why not start with your own? You should know it as well as anyone and there's only upside if you manage to crack it. After all, if you don't test your systems and networks, you'll never find — and eliminate — the weaknesses that may be exploited.

Fire up Kali Linux with Keith Barker and try some of the most common intrusion approaches, such as a brute force Wifi password crack, spoofing a network address, or snooping traffic with a 'man in the middle' attack.

Next, start competing in Capture the Flag challenges, or find some purposefully vulnerable websites to attack. Soon, you'll have moved far past the most common 17 vulnerabilities — and entered the burgeoning cybersecurity career field as a white hat hacker.