Security-guide

Web App Attacks

A web application attack is any technique that’s used to target websites, web applications and web services with malicious intent.

Barricade monitors for a variety of Web Application Attacks on your app server - suspicious activity is examined in real-time and Alerts are sent if a legitimate attack is detected.

Causes

Most web application attacks are form-based; attackers will often evaluate web forms as potential gateways as they seek out vulnerable systems to access. Barricade monitors this type of network traffic closely for any suspicious behavioural patterns.

Our engine can detect many different types of web application attack, and notifies you if a serious threat is found. Types of web application attacks can include:

  • SQL Injection
  • Cross Site Scripting (XSS)
  • Broken Authentication and Session ManagementInsecure Direct Object References
  • Security Misconfiguration
  • Sensitive Data Exposure
  • Missing Function Level Access Control
  • Cross-Site Request Forgeries
  • Using Components With Known Vulnerabilities
  • Unvalidated Redirects and Forwards

The most common type of web application attack is SQL Injection - where someone submits SQL commands through a pages’ form fields, attempting to perform admin-level actions to the connected database.

These attacks are common, but can be quite destructive if successful, resulting in data breaches or embedding malicious scripts in your website that can attack users who visit it.

Risk Levels

  Event A failed attack was detected - normally bot activity on your server
  Attack A series of failed attacks failed injection attacks were detected
  Incident A successful attack was detected - a security breach has occurred!

Recommendations

If an Incident or Attack level web app attack is detected, we recommend you take immediate action to block the source of the attack, as per the in-app Alert instructions. 

In the longer term, it’s important to be aware of the risks and prepare accordingly - testing your app for any vulnerabilities that an attacker could exploit (e.g. forms that are open to Cross-Site Scripting or SQL Injection techniques). 

Secure Your Forms
The best way to safeguard against these types of attacks in the longer term is to understand how these attacks operate, and take preventative measures to ensure your code doesn’t offer any vulnerable attack points to would-be-attackers.

Developers should use validation techniques such as parameterized statements, escaping and pattern checking to build forms that cannot be exploited through SQL Injection.

Related links:

SQL Injection

Barricade monitors for SQL Injection attacks on your application - suspicious web form activity is examined in real-time and Alerts sent if an attack is detected.  

Causes

Web forms are often targetted by attackers as they seek out vulnerable systems to access. The most common technique used in such attacks is SQL Injection - where someone submits SQL commands through a pages’ form fields, attempting to perform admin-level actions to the connected database.

See our infographic for a visual explanation of SQL Injection attacks >

https://docs.barricade.io/src/img/security-guide/sqlinjection-thumbnail-home-750.png

These attacks are common, and can be quite destructive - if successful, an attacker can interact with your database and steal or even erase sensitive data.

Risk Levels

  Event A failed SQL Injection attack was detected  
  Attack Multiple failed injection attacks were detected
  Incident A successful SQL Injection attack occurred - possible security breach

Recommendations

If SQL Injection attacks are detected, we recommend you take immediate action to block the source of the attack, as per the in-app Alert instructions

In the longer term, it’s important to be aware of the risks and prepare accordingly - testing your app for any vulnerabilites that an injection attack could exploit. 

Secure Your Forms
The best way to safeguard against SQL Injection attacks in the longer term is to understand how these attacks work, and take preventative measures to ensure your code doesn’t offer any vulnerable attack points to would-be-attackers.

Developers should use validation techniques such as parameterized statements, escaping and pattern checking to build forms that cannot be exploited through SQL Injection.

Database Backups
SQL Injection is just one of many techniques that can pose a threat to you and your data. It’s important to capture and securely store database backups to reduce the potential risk of a successful attack. 

Related links:

Cross-Site Scripting

Barricade monitors for Cross-Site Scripting attacks on your application - suspicious web form activity is examined in real-time and Alerts sent if an attack is detected.  

Causes

Cross-Site Scripting is a common method used by attackers as they seek vulnerable systems to access. These ‘XSS’ attacks involve submitting web forms with scripts and commands inserted into the input fields; in an effort to upload and embed scripts into someone’s website or app.

When successful, these scripts can be used to attack other visitors, who unknowingly load the script when they visit the infected webpage or app. Comment forms and media uploaders are often targetted by these kinds of attacks - the scripts used range in size and purpose, but have the potential to be quite destructive if successful.

Risk Levels

  Event A failed XSS attack was detected  
  Attack Multiple failed XSS attacks were detected
  Incident A successful XSS attack occurred - possible security breach

Recommendations

If Cross-Site Scripting attacks are detected, we recommend you take immediate action to block the source of the attack, as per the in-app Alert instructions

In the longer term, it’s important to be aware of the risks and prepare accordingly - testing your app for any vulnerabilites that an injection attack could exploit. 

Securing Your Forms
The best way to safeguard against XSS attacks in the long term is to understand how these attacks work, and take preventative measures to ensure your code doesn’t offer any vulnerable attack points to would-be-attackers.

Developers should ensure to properly escape and validate form field inputs to remove the possibility of exploits. It’s also a good idea to testing your app for vulnerabilities on a regular basis, to find and reinforce any points of weakness.

Related links:

Default Username Attempts

Barricade monitors for suspicious login attempts on your servers, including attacks that attempt to gain access through common, default credentials.

Causes

Login forms are commonly targeted by automated bots, as they seek out ways to access vulnerable servers. Default, out-of-the-box usernames like ‘administrator’ make it much easier for attackers to hone in on your login information, and reduce the time needed to run Brute Force password attacks.

admin  
administrator  
root  
temp  
User  
DBA

Some examples from defaultpassword.com

Risk Levels

  Event Single failed login attempt using default credentials
  Attack Multiple failed login attempts using default credentials
  Incident Successful login using default credentials - possible security breach

Recommendations

If a suspicious login attempt is detected, it’s likely that additional attempts will follow. We advise blocking the attacker’s IP address, via the Alert instructions.

In the longer term, you can safeguard against these types of attacks by following best practices:

  • Remove ‘Default’ Logins from your app
  • Create and implementing a strong password policy

Suspicious Login Attempts

Barricade monitors for suspicious login attempts on your servers, including any activity where non-existent or blocked usernames are used to try and gain access.

Causes

Login forms are commonly targeted by automated bots, as they seek out ways to access vulnerable servers. When certain behavioural patterns are observed, our engine will treat a username as suspicious and create the activity will be reported as a new case.

A username is treated as suspicious when: 

username does not exist  
username has been blocked/locked out  
username has made many failed login attempts  
username has failed activity from multiple IP addresses at once

Risk Levels

  Event Single failed login attempt using suspicious credentials
  Attack Multiple failed login attempts using suspicious credentials
  Incident Successful login using suspicious credentials - possible security breach

Recommendations

If a suspicious login attempt is detected, it’s likely that additional attempts will follow. We advise blocking the attacker’s IP address, via the Alert instructions.

In the longer term, you can safeguard against these types of attacks by following best practices:

  • Remove ‘Default’ Logins from your app
  • Create and implementing a strong password policy

SSH Login Attempts

Barricade monitors for suspicious login attempts on your servers, including any activity where non-existent or blocked usernames are used to try and gain access.

Causes

SSH servers are commonly targeted by automated bots, as they seek out ways to access vulnerable and badly configured servers. When certain behavioural patterns are observed, our engine will treat a login attempt as suspicious and create the activity will be reported as a new case.

An SSH login attempt is considered suspicious when a login failure is seen multiple times. Furthermore, if an unknown address makes fewer requests Barricade will also consider this suspicious and inform you.

These are ususally repeated login (brute force) attempts, using common usernames:

root
test
admin
oracle
guest
mysql
postgres
backup
-etc

Risk Levels

  Event Single failed SSH login attempt
  Attack Multiple failed SSH login attempts
  Incident Successful SSH login preceded by multiple failed attempts - possible security breach

Recommendations

If a suspicious SSH login attempt is detected, it’s likely that additional attempts will follow. We advise blocking the attacker’s IP address, via the Alert instructions.

In the longer term, here are some tips on strengthening your SSH security:  

  1. Use SSH Keys instead of Passwords
    It’s a good idea to use SSH keys to authenticate users, rather than passwords.

    PasswordAuthentication no

    If you’re doing this, be sure you have your keys set properly - you should make sure you’re not locking yourself out!

  2. Increase Strength
    Keys default to a key strength of 768 bits - we recommend that use are using at least 1024 or 2048 bit strength.

    ServerKeyBits 1024

    If you change this; you will subsequently need to remove your host keys and SSH will regenerate them when it restarts.

  3. Restrict Users
    You can configure SSH to permit only certain users to log in. By default all users can access SSH. By using the AllowUsers directive, you can restrict access. I like using this as it provides another layer of security. There is also an AllowGroup directive. Using the group option, you can put all approved SSH users into a group and then allow this group.

AllowUsers root admin webmaster
- Or -
AllowGroup sshusers

Gaining User Privileges

Barricade watches your network activity for any unusual behavior - including attempts to access and impersonate user accounts.

Causes

Attackers will sometimes try to assume the role of existing users, in order to access to restricted data. These attempts are pretty common - Barricade will observe your network for anything suspicious.

Risk Levels

  Event An attempt to gain user privileges was detected  
  Attack Multiple attempts to gain user privileges were detected
  Incident An attacker has successfully gained user privileges - an account has been breached

Gaining Admin Privileges

Barricade watches your network activity for any unusual behavior - including attempts to access and impersonate user accounts.

Causes

Attackers will often try to assume admin user privileges, in order to try and lock you out and access restricted data. A compromised admin user is a very serious breach - attempts are common but rarely successful.

Risk Levels

  Event An attempt to gain administrator privileges was detected  
  Attack Multiple attempts to gain administrator privileges were detected
  Incident An attacker has successfully gained admin privileges - a serious breach

Recommendations

Attempted Admin

System Information Leaks

Barricade helps protect your data by checking your traffic for any information leaks - if admin or  config information is output by the application in a response, you will be alerted immediately.

Causes

It’s important to keep any information about your systems away from prying eyes - software versions, server information, http headers - anything that could help a hacker learn about your application and the stack it’s running has the potential to uncover vulnerabilities that could be exploited.

Examples:

  • Http Header info in error messages:

    https://docs.barricade.io/src/img/security-guide/info-leak-01.png

  • Including developer comments in the page:

    e.g. <!-- if image files fails load check 192.168.0.110 --> 

  • Exposing directories:

    https://docs.barricade.io/src/img/security-guide/info-leak-02.png

Information leaks can occur in a variety of ways, depending on what language your app is written in, what software it connects to, etc. Barricade provides a layer of visibility into any weak points you may be presenting to web traffic.

In addition to system information, Barricade also monitors content on your application for any Sensitive Information (e.g. credit card or social security numbers). 

Risk Levels

  Event An attempted information leak was detected - nothing to worry about.  
  Attack Low-level information was leaked - review the revealed info.
  Incident A serious information leak was detected - a security breach has occurred!

Recommendations

If an Incident or Attack level Information Leak is detected, we recommend you take immediate action to block the source of the attack, as per the in-app Alert instructions

Blocking an IP is a short-term fix; you should immediately follow up by evaluating the issue and taking steps to ensure you pinpoint and strengthen the vulnerability that resulted in the information leak. The case page in the Barricade app will tell you the path at which the leak occurred - you should review that page and the metadata associated with the leak.

Very often, the source of the leak will be a form that returns debug information as part of the feedback that is returned to the user - perhaps some development code made it into production that shouldn’t have - you should test your app’s responses and look for any detail that would help a hacker learn about how your app is structured. 

Related links:

Sensitive Information Leaks

Barricade helps protect your data by checking for signs of sensitive information. If credit card info or content of a sensitive nature is found to be publicly visible; you will be alerted immediately.

Causes

It’s important to keep sensitive information safe online - in the wrong hands, credit card and identifying information can be used to commit fraud and identity theft. 

Barricade will help you identify any such exposed information on your systems - if someone posts credit card details to a public-facing part of your website or application, you will be alerted in real time.

Vulnerable Software

Barricade keeps an eye on the software packages on your server, checking version information for any serious lapses. Running out-of-date software greatly increases the odds of an attack on your system.

Causes

Out-of-date typically software means more vulnerable software - a lot of web app attacks specifically seek out older packages, in order to apply targetted attacks.

Risk Levels

  Event A minor vulnerability was found - you should update old software.  
  Attack A series of vulnerabilities were found - you have multiple instances of outdated software.
  Incident A serious vulnerability was found - your software urgently needs to be updated!

Recommendations

It’s important to keep your software packages up-to-date - applying patches and security fixes as they are released. Staying on top of updates will reduce your vulnerabilities.

When Barricade detects vulnerable software, the in-app case will show you out-of-date package info.

If your application or website is revealing system information (i.e. the version number) in addition to running vulnerable, older software - an attacker could discover and use that information against you. We recommend you also hide version information away from public web traffic.

Policy Violations

Barricade watches for network traffic which may be in violation of your corporate privacy policy. This includes traffic related to torrent and certain restricted websites.

Risk Levels

  Event A policy violation was detected  
  Attack Multiple policy violation was detected
  Incident A serious policy violation was detected

Trojan Infections

Barricade monitors your network traffic for any signs of a Trojan Horse infection. Any suspicious activity is examined in real-time and Alerts sent if a legitimate problem is found.  

Causes

Trojans

Unlike worms and viruses, Trojans don’t spread themselves - they usually find their way into a system through social engineering - tricking a user into installating them.

Trojans can effect you in a variety of ways - depending on the type of trojan:

  • Remote access Trojans
  • Data-sending Trojans
  • Destructive Trojans
  • Denial of service (DoS) attack Trojans
  • Proxy Trojans
  • FTP Trojans
  • Security software disablers

Risk Levels

  Event Some odd low-level activity was noticed. A common occurance.  
  Attack A Trojan has been detected - you should look into this as soon as possible.
  Incident A serious Trojan has been detected - take immediate action!

Recommendations

Your first step should be to identify the Trojan - listening to open ports and observing memory usage to help diagnosis. Scanner and Antivirus tools can help you identify the Trojan.

Trojans can limit your ability to access and remove the infection - depending on the type of Trojan, you may not be able to manually remove files - in which case the system may need to be restored to an earlier backup to ensure a clean recovery.

Related links:

How to Run Commands

You’ll need to connect to your server via SSH to run the commands - how you go about doing this depends on the type of server you’re using (AWS, DigitalOcean, Microsoft Azure, etc).

If you’re unsure about how to do this, you should refer to your Cloud provider’s documentation:

To make an SSH connection, you’ll need the following:

  1. An SSH client or Command Line Tool
  2. Username (usually root on Linux)
  3. Password and/or SSH Key
  4. The IP address of your Server

An example of the DigitalOcean’s in-browser SSH tool, where you would run the command:

https://docs.barricade.io/src/img/getting-started/do-ssh.jpeg

Blocking IP Addresses

If you’re receiving alerts that your system is experiencing an attack, we will often recommend you take action and block the attacker to prevent them from trying again.

How to Block an IP Address

To block an IP address, you’ll need to run an IPTABLES command on your server - our Alert messages present this command for you to copy:

https://docs.barricade.io/src/img/security-guide/block-ip-01.png

  1. Click the button on the right to copy the command to your clipboard.
  2. Paste and run the command on your server.

Iptables is a tool for configuring firewall rules in Linux servers - see the iptables main page for the full list of supported commands.

How to Run Commands

If you’d not familiar with running commands on your server (using SSH), see the How to Run Commands on Your Servertips.