XQuery injection attacks are sometimes thought of like the little brother to the more prevalent SQL injection attacks. They have similar root causes, and the commands that attackers exploit to trigger them both are also very close. It's just that XQuery injection attacks can only happen during an XPath query for XML data. Because of this, they are sometimes called XPath Injection or just XPath attacks, since that is the delivery method used.

A huge majority of websites use XML databases to perform critical functions such as holding user login credentials, customer information, personal identity information and confidential or sensitive data, leaving XQuery attacks with a rather large attack footprint.

In this episode, we will learn:

• How attackers use XQuery injections
• Why XQuery injections are dangerous
• Techniques that can fix this vulnerability.

How do Attackers Trigger an XQuery Injection?

Like with most computer languages, the code for XPath was designed for simplicity. In fact, XPath is a standard language, and all notations and syntax statements are unchanged regardless of the application using them. This means that the commands used to manipulate an XPath query are well known, and can even be automated.

At its core, an XPath query is a simple statement that tells the XML database what information to lookup. In one of the most simplistic examples, it is used to check to see if a user record exists, and then to retrieve their login credentials. The problem is that because XPath queries include user input, hackers can manipulate the query to return information that should be protected.

For example, when trying to bypass login security, an attacker can add variables to the end of their XPath query that circumvent the entire process. An example might look like this:

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

Here, the User Name field is made to match any user because of the 1=1 or a=a statement. The password field won't even matter, since only the first part of the query needs to be true.

Why is XQuery Injection Dangerous?

A primary reason that XQuery injection attacks are so dangerous is because they allow attackers to bypass login and account security. And they allow it to be done in an automated fashion using a standard language that does not vary by application. Attackers can automatically scan websites and applications for this vulnerability and act as soon as it's discovered. If your app is vulnerable, then the attackers will compromise it. Beyond compromising account security, XQuery attacks can also be used for data exfiltration. For example, an attacker could transfer all records out of the XML database.

Eliminating XQuery Injection Attacks

As with similar vulnerabilities, one key defense is simply not trusting user input. Any time that a user is able to enter information, whether they are making a database query or not, the process should be scrutinized. It's not unlike securing the windows and doors of a physical building, since those are the main ways people can gain access.

For XQuery injection protection, this is done by sanitizing user input through filtering, or by using whitelist input validation of user input. You can also use a parameterized XPath interface, similar to prepared statements for SQL queries.

Finally, be sure to apply least privilege to all applications. That might mean creating a user with read-only privileges to perform all application queries.

By using these techniques, it's possible to stop all XQuery injection attempts made against your website or application.

More Information about XQuery Injections

For further reading, you can take a look at what OWASP says about XQuery Injections. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

The term security misconfiguration is a bit of a catchall that includes common vulnerabilities introduced due to the application's configuration settings, instead of bad code. The most common ones normally involve simple mistakes that can have big consequences for organizations that deploy apps with those misconfigurations.

Some of the most common security misconfigurations include not disabling debugging processes on apps before deploying them to the production environment, not letting applications automatically update with the latest patches, forgetting to disable default features, as well as a host of other little things that can spell big trouble down the road.

The best way to combat security misconfiguration vulnerabilities is to eliminate them from your network before they are deployed to the production environment.

In this episode, we will learn:

• How hackers find and exploit common security misconfigurations
• Why security misconfigurations can be dangerous
• Policies and techniques that can be employed to find and fix security misconfigurations.

How do Attackers Exploit Common Security Misconfigurations?

There are a lot of common security misconfigurations. The most popular ones are well-known in hacker communities and are almost always searched for when looking for vulnerabilities. Some of the most common misconfigurations include, but are not limited to:

• Not disabling default accounts with well-known passwords.
• Leaving debugging features turned on in production that reveal stack traces or other error messages to users.
• Unnecessary or default features left enabled, such as unnecessary ports, services, pages, accounts, or privileges.
• Not using security headers, or, using insecure values for them.

Some misconfigurations are well-known and trivial to exploit. For example, if a default password is enabled, an attacker would only need to enter that along with the default username to gain high-level access to a system.

Other misconfigurations require a bit more work, such as when debugging features are left enabled after an app is deployed. In that case, an attacker tries to trigger an error, and records the returned information. Armed with that data, they can launch highly targeted attacks that may expose information about the system or the location of data they are trying to steal.

Why are Security Misconfigurations so Dangerous?

Depending on the exact security misconfiguration being exploited, the damage can range from information exposure to complete application or server compromise. Any security misconfiguration provides a hole in defenses that skilled attackers can leverage. For some vulnerabilities, such as having default passwords enabled, even an inexperienced hacker can exploit them. After all, it doesn't take a genius to look up default passwords and enter them!

Removing the Threat Posed by Security Misconfigurations

The best way to avoid security misconfigurations is to define secure settings for all apps and programs being deployed across an organization. This should include things like disabling unnecessary ports, removing default programs and features not used by the app, and disabling or changing all default users and passwords. It should also include checking for and dealing with common misconfigurations, such as always disabling debugging mode on software before it hits the production environment.

Once those are defined, a process should be put in place, one that all apps go through before they are deployed. Ideally, someone should be put in charge of this process, given sufficient power to enforce it, and also responsibility should a common security misconfiguration slip through.

More Information about Security Misconfigurations

For further reading, you can take a look at the OWASP list of the most common security misconfigurations. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Ready to thwart a security misconfiguration right now? Head to our platform and challenge yourself [Start Here]

Susie opens her email to escape from a nasty report that's due in two days. She sees a link for a free iPad appear in her inbox. After clicking it, she goes to a website with a large banner page reading, "Click here for your free iPad!". She clicks the button but nothing really seems to happen. The problem is, something did happen.

After navigating back to her inbox, she realizes all of her emails have been deleted. She didn't even hit "delete'on any of them. What's going on?

The email site was clickjacked. Clickjacking tricks users into performing actions they didn't intend to perform, and it can lead to serious problems.

Let's take a look now at how clickjacking works, why it's dangerous, and what developers like you can do to prevent it:

Understand Clickjacking

Clickjacking, also called a "UI redressing attack", occurs when an attacker uses several transparent layers on a web page to trick the user into clicking on a button or link the user doesn't intend to click on.

Have you ever had a bug stuck in your car? They fly up against the window furiously trying to fly outside. The bug's intention is to fly to what looks like trees and open air, oblivious of the glass blocking its path.

Clickjacking is similar in design, except the user is the bug and your website is the glass blocking the way. The user sees something they want, such as a free iPhone. The attacker places your site inside a transparent frame on top of the free iPhone ad. When the user clicks on the button to grab the allegedly "free'prize, they are actually clicking on a button on your site, performing an action they didn't intend.

Why Clickjacking is Dangerous

What can an attacker do with clickjacking? It largely depends on the functionality of the website in question.

The attacker could get a user to like or share the attacker's site on social media. This can be easily pulled off since many people stay logged into their social media accounts for convenience purposes.

If your site can be placed in a frame, a sensitive operation can be completed by clicking a button, and this can act as an attack vector. For example, a user clicks to get a free iPad but instead changes account settings on your site to make the account less secure. An attack of this type occurred against the Adobe Flash plugin settings page. The settings could be placed in a transparent frame, tricking the user into allowing any Flash animation access to the microphone and camera. Attackers could then record the victim; a major invasion of privacy.

An email client could be framed into a site, causing the user to delete all emails in their mailbox or forward emails to an email address controlled by the attacker.

The bottom line is: the user can't see what they're clicking, so they can be convinced to click anything. Whether it is a social share or downloading malware, the possibilities are vast.

How to Defeat Clickjacking

Clickjacking can be prevented. The recommended way to prevent clickjacking is to define a content security policy, or CSP, for your site. Using the "frame ancestors" HTTP response header, you can control how your site can be framed.

• "frame-ancestors none'- No other site is allowed to frame yours. This is the recommended setting.
• "frame-ancestors self'- Pages in your site can only be framed by other pages within your site.
• "frame-ancestors self <uri list=""> - Your site can be framed by the sites in the URI lists and no others.</uri>

CSP frame-ancestors is not currently supported by all major browsers. Use the "X-Frame-Options" HTTP header as a fallback option for such browsers.

• DENY - No one can frame your site. This is the recommended setting
• SAMEORIGIN - The same as "self'for CSP. You can frame your own content, but no-one else can.
• ALLOW-FROM <uri> - Allow the specified URI to frame your content.</uri>

Don't Get Clickjacked

Clickjacking is a clever, misleading attack that can lead to reputational damage and revenue loss if your product can be manipulated by attackers. Check out our free learning resources to find out more about clickjacking.

Use a Content Security Policy and "X-Frame-Options" header to prevent others from using your site in malicious ways. Don't allow attackers to manipulate your users. Don't get clickjacked.

An OS command injection attack can happen whenever an application allows users to make input into a shell, but takes no actions to verify that the input strings are valid. This enables an attacker to drop commands directly into the operating system hosting the application, and at whatever permission levels are set for the compromised application.  

OS command injection attacks can be performed by entry-level and less skilled hackers, which makes them one of the most common weaknesses that security teams experience. Thankfully, there are quite a few very effective ways to prevent them from being successful. In this episode, we will learn:

       How they work

       Why they are so dangerous

       How you can put defenses in place to stop them.

How do Attackers Use OS Command Injection?

The first thing that an attacker must do in order to initiate an OS command injection attack is to locate user inputs within an application. Forms that users fill out are potentially good jumping off points. The most clever attackers can also use things like cookies or even HTTP headers as their launching point, something used by almost every application or website.

The second thing they need to do is figure out what operating system is hosting the application. Given that there are only a handful of choices, trial and error can work just fine for this phase. Most application servers are either going to be Windows-based (the flavor of Windows does not normally matter), some type of Linux box, or possibility Unix.

At that point, the hacker modifies the input to inject an operating system command into seemingly innocuous input. This can trick the hosting OS into executing unintended commands at whatever permission level the application has.

For example, the following command can be used by valid users within an application to see the contents of a file, in this case the notes from a monthly board meeting.

exec("cat " + filename)

In our example, this would execute the following command and return the meeting notes back to the user.

$ ./cat MeetingNotes.txt

There were three members of the executive committee present at the July meeting. The new budget project was discussed, but no actions or votes were taken.

This is what happens when an attacker adds additional commands at the end of the input, such as the one used to list contents of a directory in Linux. In this case, the original command, displaying the meeting notes, still happens. But the malicious user is also shown everything else is in the directory, and what other commands they can use on follow-up OS command injection attacks. They enter:

$ ./cat MeetingNotes.txt && ls

And get this instead:

There were three members of the executive committee present at the July meeting. The new budget project was discussed, but no actions or votes were taken.

MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c

As you can see, in this case, not only was the hacker shown the contents of the directory, but also given a menu of other commands that they could use " commands they now know they can execute on the host operating system.

Why are OS Command Injection Attacks so Dangerous?

Allowing users to bypass the purpose of the targeted application and use it to run operating system commands is extremely risky. An attacker can easily perform devastating actions such as stealing confidential data or formatting an entire server drive for example. The options available to an attacker are only limited by the allowed commands within the operating system and their creativity in using them.

OS commands are run at the same permission level as the application. Apps running with administrative privileges means hackers that compromise them can run every OS command.

The attack patterns for OS Command Injection are well known and documented. A vulnerable application is just as susceptible to script kiddies as it is to professional hackers. Attackers with very little skill can attempt to cut and paste OS commands into applications to see what happens.

Getting A Security OK against OS Command Injections

There are several good techniques that can stop OS command injections. The first step is to run applications with the least amount of privileges needed to accomplish their function. This does not prevent an attack, however if a breach does occur, the damage is minimized.

Most programming languages and frameworks provide API calls for common OS methods such as listing directory contents, creating or reading files on hard disk. One perfect way to eliminate OS command injections from your environment is to have all applications use these API calls instead of OS commands directly.

Where this is not possible, validate user inputs before using them in OS commands. Whitelists can be used to ensure only a small set of trusted values can be used. It's technically possible to do this using a blacklist too, but there are probably far fewer allowed commands, so whitelisting is almost always easier. Don't forget to include valid POST and GET parameters in your whitelist, as well as often overlooked user input vectors like cookies.

Lastly, if there is no programming API available and a whitelist cannot be used, use a sanitization library to escape any special characters in user inputs before using them in OS commands.

More Information about OS Command Injection Attacks

For further reading, you can take a look at the OWASP writeup on OS command injection attacks. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

You navigate to a website and log in. As normal, you fill up your cart with products you'd like to buy. Then, whoops - your hand slips and closes the browser tab. After a minor panic, you enter the URL of the site back into the browser and hit the "Enter" key. You are brought back into the site, logged in, and all of your items are still in the cart. Whew.

How did the site know who you were without re-authenticating? It identified you because it was using sessions. Sessions are key to a good user experience when using the web. However, managing sessions incorrectly can lead to security holes that attackers can exploit.

Let's now review what session management means, how weak session management can hurt you, and what you can do to manage sessions properly.

Understanding Session Management Weaknesses

A session refers to a value stored on the server, specific to a single user of the application. This is necessary for two reasons: First, HTTP is a stateless protocol. Each request is separate and has no knowledge of requests that have come before or after it. A session helps the server track who sent the request. Otherwise, you would need to login every time you clicked on a button or a link.

The second reason for sessions is for authorization of the user. The session identifier can be used to recognize a specific user with specific rights within the system. The application will know who the person is and what they are allowed to do.

There are two components to a session. A data store on the server-side stores a session identifier and maps it to information about the user such as their user id or cart information. The same session identifier is sent to the browser in a cookie. The cookies are stored by the browser on the user's system. The client passes the cookie with each request, letting the server knows that this request is coming from the same user. Most applications use sessions to track users both pre- and post-authentication.

Proper session management is essential to the security of an application. A valid session ID has the same level of trust as a username/password, or even a second-factor authentication token.

Why Poor Session Management is Dangerous

Poor session management can lead to complete account takeover. This means customer data can be stolen, or products could be purchased fraudulently. There are several ways for attackers to obtain a valid session ID.

A session fixation attack occurs when sessions are not changed at key times, such as when a user logs into the system, and if session identifiers can be set using the URL. Setting session identifiers in this way may be used to keep users logged in across different applications that use the same authentication source. In this case, an attacker can browse to a website and gain a session ID. The attacker then sends a URL to an unsuspecting victim via email with the session ID in the URL. The victim clicks the URL in the email and logs into the website. If the session ID is not rotated upon login, the attacker now has a valid, authenticated session ID. This allows complete account takeover.

Another attack upon poor session management is a brute-force guessing attack. When developers try to create their own session management systems, often they use session IDs that are pretty simple to guess. These could be a sequence (1, 2, 3) or a predictable pattern of some kind. The attacker simply keeps guessing session IDs until a valid one is discovered. This also leads to an account takeover.

Sessions that aren't invalidated automatically after a certain amount of time has passed can be exploited to attack users. A successful cross-site request forgery attack depends on sessions that are still valid after the user leaves the site. Let's say an attacker places an iframe or image on a site visited by the user. The "src" (source) attribute is set to the URL of the vulnerable site and performs an action on behalf of the user. For example, a vulnerable banking application could be made to transfer money to an attacker's account without the user's permission.

Session management can be tricky, and weaknesses can be devastating. However, it's a well-known problem and it can be solved.

Defeat Insecure Session Management

Session management is a core piece of any web application. As a result, many web development frameworks have built-in session management functionality. These systems have been scrutinized by experts to find and weed out problems. Use them.

Some common properties of good session management include:

     Random session IDs generated that attackers can't guess

     Sessions are invalidated when a user logs out

     Sessions are invalidated automatically after a certain amount of time has passed

     Session IDs are changed after the user logs in

     Session IDs that are at least 128 bits long to prevent brute force attacks

Web frameworks such as Spring, ASP.NET Core, Rails, and Django have these properties and should be used for their higher security standards in this instance.

Bottom line: Don't create your own session management system from scratch.

Once the session IDs are created, they need to be protected. Set the Secure and HttpOnly flags to "true'on session cookies. This ensures that their value cannot be retrieved with JavaScript and the browser will only send the cookie via HTTPS, preventing attackers from stealing someone's session in transit.

Secure Your Sessions

Check out our free learning resources to find out more about secure session management. Learning how to secure your sessions will help prevent user account takeover, reputation damage, and lost revenue due to security breaches. Secure your sessions and keep your users safe.

While Padding Oracle sounds like a really bad name for an alternative rock band, it's actually a vulnerability that can be used by attackers to decrypt information without knowing the encryption key.

In terms of overall difficulty for an attacker, this one is near the top of the scale. We are not talking about a magic decryption button, but instead, a laborious process whereby hackers can examine error messages sent to them regarding cell padding, and use that to determine where encrypted data ends and the padding begins. They can then figure out various bits within the encryption, and possibly crack it given enough time and input to examine.

Thankfully, there are several relatively easy steps that can remove an attacker's ability to use padding oracle to decipher encrypted data. In this episode, we will learn:

• How it works
• Why this vulnerability is so dangerous
• How you can put defenses in place to prevent it.

How Does Padding Oracle Work?

Cipher block chaining (CBC) is a way to create a block cipher where an entire sequence of bits of information, such as cells stored within a database, are encrypted using an encryption key that applies to the entire chain of information. When using CBC, the encryption of a single block of ciphertext will depend on all of the proceeding blocks. In theory, this makes the encryption extremely strong, since anything, even the reordering of the blocks, will corrupt the data.

The problem with CBC ciphers (and any block ciphers, for that matter) is that they can only be encrypted using blocks of exact sizes. Normally, this is done in 8 or 16-byte sizes. So what happens when CBC needs to fit 2 bytes of data into a 16-byte ciphertext unit? It will use padding, basically just nonsense characters, to fill in the gaps and make the unit an appropriate size.

Most padding schemes are well known, with PKCS#7 being one of the most popular, so attackers might know what kind of padding is being used. For example, if the CBC needs to pad five characters in a block, PKCS#7 would use the byte value 0x05 repeated five times after the plain text.

Attackers use their knowledge of both CBC and padding schemes to send queries to a host server, also referred to as an oracle. If they have access to the right tools, they may be able to force the server to tell them if the padding in their query is incorrect. Achieving this, they can cycle from zero to 255 for every byte in the cipher until the server tells them that the padding is correct. Then, they move on to the next unit and repeat the process, recording where the padding begins in every case.

This does not let them decrypt the message or even the cell, but could allow them to map every link in the chain in terms of where the plain text ends and the padding begins. They can also potentially use XOR calculations to figure out the value of the last byte of the original plain text.

Why is Padding Oracle so Dangerous?

The reason why a hacker would put so much work into breaking encryption is because of the potential payout. Few people encrypt things that aren't valuable. The danger to the host organization depends on the data being compromised. That could include things like passwords, user accounts, financial information, credit card numbers, patient records, sensitive communications, or any number of highly sought-after and valuable pieces of information.

Using padding oracle could also be the gateway to subsequent attacks. If an attacker can use padding oracle to steal passwords for example, then elevating their privileges and penetrating deeper into a network is an easy secondary task.

Everyone thinks of encryption as the ultimate defense against snooping or compromise. However, the back-and-forth between encryption science and those that would break it has been going on for centuries. Padding oracle is just one method that gives the edge to attackers.

Giving Padding Oracle Attacks a Hard Landing

Thankfully, there are quite a few ways to prevent padding oracle. One of the best is to use stronger encryption mode of operations such as Galois/Counter Mode (GCM) or Offset Codebook Mode (OCB). It differs from CBC in that it uses a cipher block size of 128 bits. It also uses a counter for each block of data, then uses that number to create the ciphertext. In other words, it is not susceptible to padding oracle attacks.

Implementing good error handling controls can also severely hurt an attacker's chances of success. Since padding oracle attacks rely on information leakage, return generic error messages instead of specific padding errors on encryption/decryption failure.

You can also implement Message Authentication Code (MAC). MAC values protect the data integrity as well as its authenticity, by allowing verifiers to detect any changes to the message content using a secret key.

Finally, all padding oracle attacks require repeated queries. There can be over 200 requests made to figure out the padding scheme on a single cell, multiplied by the number of units of information being protected in the chain. By restricting the number of requests coming in from the same source, you can shut down padding oracle attacks by denying an attacker access before they can really begin their attempt.

Further Study on Padding Oracle

Any method by which an attacker can decrypt sensitive information can become a real nightmare. But, we hope you have learned quite a few good methods for preventing that from happening in the first place.

For further reading, you can take a look at the OWASP definition and checklist on padding oracle. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre up to the task of thwarting padding oracle attacks right now? Try it on the Secure Code Warrior platform:

The vast majority of computer systems use Lightweight Directory Access Protocol (LDAP). It's used to maintain distributed directory information services over any Internet Protocol (IP) network. So basically, it functions as a way to keep track of users.

LDAP is often used as an authentication source by apps to see if a user has permission to perform various actions, especially as it pertains to their defined role within an organization. For example, only those in accounting might be able to use company accounting software. Applications will often be programmed to check an LDAP table to ensure that users are acting within their established permissions.

Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.  

LDAP injections can be tricky, but in this episode, we will learn:

• How they work
• Why they are so dangerous
• How you can put defenses in place to stop them.

How do Attackers Use LDAP Injection?

One of the reasons that LDAP-based attacks have remained popular for years is the fact that almost every computer system uses it. LDAP is open-source and works extremely well, so not a lot of alternatives have been created.

At its core, LDAP is a database that tracks valid users within an IP-based computer system or network. It can allow users to share information about systems, networks, servers, applications and even other users on the same network.

Information is stored by LDAP in the equivalent of a database line or record that is called a distinguished name, which is often abbreviated as DN. Each DN is unique. As an example, this is what a DN might look like for a user who works in the Chicago accounting office of a large corporation.

cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview  

To ensure that each DN is unique, various codes can be added to the record, such as "+", "/", "=" and a few others. Spaces before or after a record can also be inserted to ensure that even if there are two James Smiths working in Corporate Accounts in the Chicago Parkview Office, they will each have individual DNs.

Applications generally use LDAP to allow users to send queries about specific DNs, such as, for example, when trying to locate the correct contact in the payroll department to talk about a mistake on their check. LDAP injections can happen when there is no validation of the user-provided parameters in search queries. In that case, hackers can manipulate benign searches to bypass authentication mechanisms or execute additional arbitrary queries. This can trick the server into displaying results that should not be allowed, such as user passwords, or even cause an application to grant access to high-security areas within the network, with or without a valid password.

Why are LDAP Injections so Dangerous?

The biggest danger with LDAP injections is likely the proliferation of the protocol throughout the majority of IP computer networks worldwide. It makes for an easy stepping stone for hackers looking to steal information, or to elevate their privileges on a network. No trained hacker will fail to check if LDAP injections are possible, so security teams must ensure that those holes are always closed.

Specifically, quite a few applications are programmed to help valid users find limited information about users and groups within an organization, or any other information contained in the DNs. For example, an app might allow someone to use LDAP to search for the contact information of corporate accountants working in Chicago, which would return our friend James Smith from the above example. Depending on permissions, this is likely a perfectly valid use of an LDAP query.

The danger comes when a malicious user can add parameters unfiltered the query, changing the nature of the search and tricking the server into providing information that should not normally be given. For example, by adding a user=* string, attackers could get information about every single user at an entire organization, something that should probably never be allowed.

For applications that use LDAP for authentication, the problem can be even worse. Attackers can use, for example, the (&) string at the end of an LDAP query to trick the server into thinking the argument is true. If an app uses LDAP to validate a password, forcing a True argument through an LDAP injection might allow an unauthorized user to log into the network as an administrator, even without a password.

Making LDAP Injection an L-DON'T in your Network

One of the best ways to prevent LDAP injections is to implement something like LINQtoAD or other frameworks designed specifically to resist it. This may not be possible if a network already has   applications that are leveraging LDAP queries. However, even in that case, it's still a good idea for every new application to use injection-resistant frameworks moving forward.

Existing applications that use LDAP can also be hardened against injections through the use of whitelist validation and input sanitization. Where possible, restrict user input to a limited set of trusted values. Otherwise, user input that is part of an LDAP query should be sanitized first, and don't forget to include GET and POST parameters, cookies and HTTP headers as they can also act as attack vectors. Do not write your own functions to perform input sanitization; use a trusted third-party security focussed library or built-in framework APIs instead.

Beyond targeted fixes, good computing practices like assigning LDAP querying applications the least privilege needed on a network can also help. That way, if the worst should happen and an LDAP injection gets through, the damage would be mitigated.

More Information about LDAP Injections

For further reading, you can take a look at the OWASP writeup on LDAP Injections, or the injection prevention cheat sheet. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

The Unrestricted File Uploads problem is not an attack itself, but instead a common situation or state that allows attackers easy access to applications and network resources. You can think of it sort of like walking around in wet clothing out in the cold. While doing that won't necessarily make you sick on its own, it lowers your resistance to the point where any opportunistic virus will easily overwhelm your body's defenses.

In cybersecurity, attackers can be quick to exploit any application or program that has been allowed to support unrestricted file uploads. And the results can be devastating. Clever attackers can use their unrestricted access to upload malicious files, set up scripts to steal credentials or launch deeper attacks into a network using an application's own permissions. Even a relatively unsophisticated attacker could use this kind of unfettered access to perform denial of service attacks, or to crash an application.

Thankfully, there are quite a few ways to conquer the Unrestricted File Uploads problem that will stop would-be attackers in their tracks. To that end, we'll discuss three key aspects of Unrestricted File Uploads:

• How they work
• Why they are so dangerous
• How you can put defenses in place to stop them.

How Do Attacks Exploit Unrestricted File Uploads?

There are a lot of reasons why sites would want to allow the public to upload files. Perhaps a company is looking to hire people, and wants to allow them to upload their resumes as part of the application process. Banks may encourage customers to fill out important paperwork at home, such as when applying for a loan or a new account. Tourism or social media sites may invite users to upload their photographs for sharing with others.

There are lots of valid reasons to allow file uploads. And by default, most new applications are probably going to allow any type of file upload, without restrictions. The trouble begins when a potential attacker notices that there are no restrictions placed on those uploads.

Having no restrictions on uploads subjects sites to three types of attack. Starting with the least sophisticated, a malicious user can simply upload huge files such as zipped archives containing hundreds of gigabytes of information. Besides choking off bandwidth, this can overload the storage area assigned to the application.

Next up on the infamous ladder is a user who uploads a malicious file like a virus or even something more sinister like ransomware. This is sort of like that old superstition of having to specifically invite a vampire into your home. If you hang out a sign that says anyone can come in freely, it's just like having unrestricted file uploads. You no longer control what comes through your door, and you should probably expect that not every visitor, or file, is going to be benign. Some of them might be monsters.

Finally, a skilled attacker can use unrestricted uploads to gain a foothold into a network for deeper attacks. Because there are no restrictions on what someone can upload, an attacker can send their own web shell through that process. Thereafter, they can send commands into their shell, and those commands will be executed on the server with the same permission level as the application.

Why is Having Unrestricted File Access so Dangerous?

While deploying an application with unrestricted file access isn't immediately dangerous, it's basically like opening up a hole in your cybersecurity defenses and inviting someone to attack your organization. Sooner or later, someone will respond.

At the most basic level, attackers don't even need a lot of skill to wreak havoc. Simply zipping up extremely large files and uploading them might be enough to deny service to valid users. Over time, it can even crash the application or an entire site, depending on how the app is programmed and networked.

Having unrestricted file access also might open a hole through network firewalls and other protections. It won't matter if you have a scanner looking at your incoming e-mail or your employee web browsing activity if you have created a path for attackers to upload malware directly to your core network. The malware might crash the application or even the server it's running on, though that is probably the best possible outcome. In a worst-case scenario, a truly malicious program like ransomware can use the compromised server to spread out to the entire network.

More skilled attackers probably won't be so obvious when exploiting an application with unrestricted file access. Instead, they can use the vulnerability to compromise the application, and use that to penetrate deeper into the network, moving slowly and trying to avoid detection. This can be done by uploading a web shell or other .exe type file, and then sending commands directly to it once it lands. Anything that the user runs through their shell will normally be executed by the server, using whatever permission levels are set for the application hosting it. To the server, those commands are coming from the application, and are not likely to be further checked or examined.

All of that makes the unrestricted file access vulnerability one of the most dangerous to have on your network. It's probably not a question of if it will cause a problem, but when.

How Do I Eliminate the Unrestricted File Access vulnerability?

So, how do you solve the unrestricted file access problem? The easiest way is simply to add one or a number of restrictions on the types of files that can be uploaded. These can be communicated to the user if you want, for example, telling them that the site will only accept Word or text files, or in the event of a picture sharing site, only .jpgs or .gifs. On the backend, you will need to create a whitelist of acceptable file extensions and then deny everything else. Restrictions should also be placed on the maximum length of file names. If a file has special characters in the name, which might indicate an attempt to trigger an executable command, it should likewise also be rejected.

In addition to file types and naming rules, you are also going to want to restrict the maximum size of each file. The maximum size should be something reasonable and appropriate for the type of file the application is expected to collect. That might mean a cap of 10 megabytes or so for Word files and something a bit larger, perhaps around 50 megabytes, for graphical files. It's also possible to set minimum file size rules, but only if the size range of the expected files are well-known, which might be the case if users are filling out and uploading a specific form.

Attackers may still find a clever way to sneak a shell or other potentially malicious program past file type and size restrictions. To compensate, collected files should always be stored in a private directory with no execution privileges. For added security, files can be renamed by the system to a series of random characters. This would prevent unauthorized users from outside the network from searching for the location of their uploaded file, which might give them some recon into your network. If you do that, however, you will probably need to set up and maintain a table linking the random file names to their original designations.

Finally, anything that arrives in the network via an upload should be scanned for malware and viruses by whatever defensive programs the organization uses for those tasks. This might not catch everything, but is an important layer of security that could be used to detect up to 90 percent or more of the most common malicious files trying to enter via file upload.

Restricting the Unrestricted File Upload Problem

Once several layers of security are put in place on the backend, the Unrestricted File Upload problem ceases to become an issue. You are basically eliminating the issue by placing restrictions on your file uploads, hence they are no longer unrestricted. Only good files are allowed inside, while all the vampires and malware are left out in the cold.

For further reading, you can take a look at the OWASP Unrestricted File Upload Prevention Cheat Sheet, which outlines some of the most common problems when this kind of situation is allowed on a network. You can also put your newfound defensive knowledge to the test with the free showcase of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to tackle this vulnerability right now? Head to the battlefield and test your skills:

NoSQL databases are becoming more and more popular. It's hard to deny their speed and ease of dealing with unstructured data, especially with dev teams working to increasingly agile methodologies.

It takes time for developers to shake out vulnerabilities and other challenges in emerging technology. Only after it has been in use for some time in production applications do problems begin to bubble to the surface.

NoSQL databases are similar. There are key risks developers should be aware of so they can keep their applications safe. One such risk is NoSQL injection.

Let's take a look at what NoSQL injection is, what damage it can cause, and how to fix it:

Understand NoSQL Injection

NoSQL injection is caused by many of the same injection vulnerabilities such as XML or SQL injection.

NoSQL injection allows attackers to place arbitrary commands into a NoSQL query. This allows them to steal data and even make changes to the database if their privileges are high enough.

When an application places user-controlled data directly into a NoSQL query expression, these expressions often take functions or have built-in operators that can be manipulated to steal or change data. And when such a thing is executed with malicious intent, the consequences can be dire.

MongoDB databases are one of the most popular playgrounds to exploit with this vulnerability. "$ne: ""'is the operator equivalent to 1=1 in the SQL world, so, by way of example, an attacker could place the characters "$ne: “”’ into the username and password fields of a UI. If the code is vulnerable to NoSQL injection, the database will search for all records where the username and password do not equal an empty string. In other words: all of them. Yikes.

If this database is unencrypted, then the attacker could steal the usernames and passwords of every single user within it. This includes administrator username and passwords, giving them an all-access pass to the entire database.

Attackers often try to pass-in values that are always true. Another common attack is to inject malicious code into properties that are set to functions.

For example, MongoDB uses a find function that takes an object with a property called $where. The $where property is set to a function that should evaluate to true or false. If this function is changed in any way by user input, a NoSQL injection likely lurks there.

For a nicely detailed look at the intricacies of NoSQL injection, check out this InfoQ article.

Know Why NoSQL Injection is Dangerous

NoSQL injection is dangerous mostly because it hasn't yet received the scrutiny from the security community it deserves.

The impacts of NoSQL injection are much the same as with traditional SQL injection. Data can be stolen or changed, accounts can be compromised by stealing data and, perhaps most viciously, data could be completely wiped out if a delete command is successfully issued.

The bottom line is that MongoDB and other NoSQL database engines are vulnerable to attack. "No SQL" doesn't mean no injections.
Thankfully, some in the community are taking note and putting the word out. More developers need to educate themselves so they can protect their apps from little-known nasties that can become a huge headache if exploited.

Defeat NoSQL Injection

NoSQL injection can be difficult to defeat. Unfortunately, there isn't the option of parameterized queries as there is with SQL injection. However, it's not impossible. There are a few options to help you out:

• Fuzzers can be used as one method to detect vulnerabilities. Although, as is the case with many things in life, the simplest approach can be the most effective. Here, good old code review is your strongest ally.
• When reviewing code, look for possible places where user input could set the value of an expression or change a function. Don't allow user input to change your queries.
• Be sure to cast user input to its rightful class. If its a number, cast it to a number, if its a string, cast to a string and so on.
• Never use $where or similar eval functions along with user input. In most cases, you can work around it by changing the data model or schema.
• Try using Mongoose as your MongoDB driver. Mongoose allows you to define a schema for your NoSQL database. If you tell Mongoose that your inputs are strings, they will be cast to strings. So, any objects passed in by an attacker will not be treated as objects, but as strings.
• Harden your DB! Create low-privilege user accounts, maximize execution time for queries, and always follow the security best practices that apply to your organization.

A disadvantage of NoSQL databases'ease of use is the tendency of developers to stand them up and start using them with no thought about security.

It's essential that you take the time to learn how to securely stand up a NoSQL database and protect yourself from NoSQL injections.

For instance, MongoDB Enterprise Edition has advanced access control capabilities for your documents. Enforcing "least privilege'can be a good Defense in Depth (DiD) strategy in case someone were to find a vulnerability in your application.

To sum up, here's what we have:

• Sanitize your input before using it in a NoSQL query expression
• Use drivers that help you out, like Mongoose
• Perform code reviews that look specifically at how input data is used within queries
• Use fuzzers and scanners to try to help find vulnerabilities in your code.

NoSQL is not No Injections

NoSQL databases are quickly gaining popularity due to their scalable features and speed of setup. The newness of the technology can lead developers to use NoSQL databases without thinking of how to secure them.

NoSQL databases can be just as vulnerable as SQL databases to injection attacks, so act with caution and pay attention to your queries. If you want to learn more, check out our Learning Resources or test your skills with our free demo.

Prepare yourself ahead of time and you won't need to worry about NoSQL injections in your applications. Too easy!

Think youre ready to locate, identify and fix NoSQL injection right now? Enter the secure code arena, warrior:

And thats a wrap for 2018! This will be our final post for the year, but well be back with the next Coders Conquer Security guide on January 10th, 2019. See you soon!