main

Application Security

4 Emerging Challenges in Securing Modern Applications

May 1, 2019 — by Radware0

appsecurity-960x474.jpg

Modern applications are difficult to secure. Whether they are web or mobile, custom developed or SaaS-based, applications are now scattered across different platforms and frameworks. To accelerate service development and business operations, applications rely on third-party resources that they interact with via APIs, well-orchestrated by state-of-the-art automation and synchronization tools. As a result, the attack surface becomes greater as there are more blind spots – higher exposure to risk.

Applications, as well as APIs, must be protected against an expanding variety of attack methods and sources and must be able to make educated decisions in real time to mitigate automated attacks. Moreover, applications constantly change, and security policies must adopt just as fast. Otherwise, businesses face increased manual labor and operational costs, in addition to a weaker security posture. 

The WAF Ten Commandments

The OWASP Top 10 list serves as an industry benchmark for the application security community, and provides a starting point for ensuring protection from the most common and virulent threats, application misconfigurations that can lead to vulnerabilities, and detection tactics and mitigations. It also defines the basic capabilities required from a Web Application Firewall in order to protect against common attacks targeting web applications like injections, cross-site scripting, CSRF, session hijacking, etc. There are numerous ways to exploit these vulnerabilities, and WAFs must be tested for security effectiveness.

However, vulnerability protection is just the basics. Advanced threats force application security solutions to do more.

Challenge 1: Bot Management

52% of internet traffic is bot generated, half of which is attributed to “bad” bots. Unfortunately, 79% of organizations can’t make a clear distinction between good and bad bots. The impact is felt across all business arms as bad bots take over user accounts and payment information, scrape confidential data, hold up inventory and skew marketing metrics, thus leading to wrong decisions. Sophisticated bots mimic human behavior and easily bypass CAPTCHA or other challenges. Distributed bots render IP-based and even device fingerprinting based protection ineffective. Defenders must level up the game.

[You may also like: CISOs, Know Your Enemy: An Industry-Wise Look At Major Bot Threats]

Challenge 2: Securing APIs

Machine-to-machine communications, integrated IoTs, event driven functions and many other use cases leverage APIs as the glue for agility. Many applications gather information and data from services with which they interact via APIs. Threats to API vulnerabilities include injections, protocol attacks, parameter manipulations, invalidated redirects and bot attacks. Businesses tend to grant access to sensitive data, without inspecting nor protect APIs to detect cyberattacks. Don’t be one of them.

[You may also like: How to Prevent Real-Time API Abuse]

Challenge 3: Denial of Service

Different forms of application-layer DoS attacks are still very effective at bringing application services down. This includes HTTP/S floods, low and slow attacks (Slowloris, LOIC, Torshammer), dynamic IP attacks, buffer overflow, Brute Force attacks and more. Driven by IoT botnets, application-layer attacks have become the preferred DDoS attack vector. Even the greatest application protection is worthless if the service itself can be knocked down.

[You may also like: DDoS Protection Requires Looking Both Ways]

Challenge 4: Continuous Security

For modern DevOps, agility is valued at the expense of security. Development and roll-out methodologies, such as continuous delivery, mean applications are continuously modified. It is extremely difficult to maintain a valid security policy to safeguard sensitive data in dynamic conditions without creating a high number of false positives. This task has gone way beyond humans, as the error rate and additional costs they impose are enormous. Organizations need machine-learning based solutions that map application resources, analyze possible threats, create and optimize security policies in real time.

[You may also like: Are Your DevOps Your Biggest Security Risks?]

Protecting All Applications

It’s critical that your solution protects applications on all platforms, against all attacks, through all the channels and at all times. Here’s how:

  • Application security solutions must encompass web and mobile apps, as well as APIs.
  • Bot Management solutions need to overcome the most sophisticated bot attacks.
  • Mitigating DDoS attacks is an essential and integrated part of application security solutions.
  • A future-proof solution must protect containerized applications, serverless functions, and integrate with automation, provisioning and orchestration tools.
  • To keep up with continuous application delivery, security protections must adapt in real time.
  • A fully managed service should be considered to remove complexity and minimize resources.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

SecurityService Provider

Bot Management: A Business Opportunity for Service Providers

April 30, 2019 — by Radware0

BotManagementSP-960x540.jpg

Over half of all internet traffic is generated by bots — some legitimate, some malicious. These “bad” bots are often deployed with various capabilities to achieve their nefarious objectives, which can include account takeover, scraping data, denying available inventory and launching denial-of-service attacks with the intent of stealing data or causing service disruptions. Sophisticated, large-scale attacks often go undetected by conventional mitigation systems and strategies.

Bots represent a clear and present danger to service providers. The inability to accurately distinguish malicious bots from legitimate traffic/users can leave a service provider exposed and at risk to suffer customer loss, lost profits and irreparable brand damage.

In an age where securing the digital experience is a competitive differentiator, telecommunication companies, management services organizations (MSOs) and internet service providers (ISPs) must transform their infrastructures into service-aware architectures that deliver scalability and security to customers, all the while differentiating themselves and creating revenue by selling security services.

[You may also like: Bot Managers Are a Cash-Back Program For Your Company]

Bot Traffic in the Service Provider Network

Bot attacks often go undetected by conventional mitigation systems and strategies because they have evolved from basic scripts into large-scale distributed bots with human-like interaction capabilities. Bots have undergone a transformation, or evolution, over the years. Generally speaking, they can be classified into four categories, or levels, based on their degree of sophistication.

The four categories of malicious bots.

In addition to the aforementioned direct impact that these bots have, there is the added cost associated with increased traffic loads imposed on service providers’ networks. In an age of increased competition and the growth of multimedia consumption, it is critical that service providers accurately eliminate “bad” bots from their networks.

[You may also like: The Big, Bad Bot Problem]

Staying ahead of the evolving threat landscape requires more sophisticated, advanced capabilities to accurately detect and mitigate these threats. These include combining behavioral modeling, collective bot intelligence and capabilities such as device fingerprinting and intent-based deep behavioral analysis (IDBA) for precise bot management across all channels.

Protecting Core Application from Bot Access

Bots attack web and mobile applications as well as application programming interfaces (APIs). Bot-based application DoS attacks degrade web applications by exhausting system resources, third-party APIs, inventory databases and other critical resources.

[You may also like: How to Prevent Real-Time API Abuse]

IDBA is now one of the critical capabilities needed to mitigate advanced bots. It performs behavioral analysis at a higher level of abstraction of “intent,” unlike commonly used, shallow “interaction”-based behavior analysis. IDBA is a critical next-generation capability to mitigate account takeovers executed by more advanced Generation 3 and 4 bots, as it leverages the latest developments in deep learning and behavioral analysis to decode the true intention of bots. IDBA goes beyond analyzing mouse movements and keystrokes to detect human-like bots, so “bad” bots can be parsed from legitimate traffic to ensure a seamless online experience for consumers.

API Exposure

APIs are increasingly used to exchange data or to integrate with partners, and attackers understand this. It is essential to accurately distinguish between “good” API calls and “bad” API calls for online businesses. Attackers reverse engineer mobile and web applications to hijack API calls and program bots to invade these APIs. By doing so, they can take over accounts, scrape critical data and perform application DDoS attacks by deluging API servers with unwanted requests.

Account Takeover

This category encompasses ways in which bots are programmed to use false identities to obtain access to data or goods. Their methods for account takeover can vary. They can hijack existing accounts by cracking a password via Brute Force attacks or by using known credentials that have been leaked via credential stuffing. Lastly, they can be programmed to create new accounts to carry out their nefarious intentions.

[You may also like: Will We Ever See the End of Account Theft?]

As its name suggests, this category encompasses an array of attacks focused on cracking credentials, tokens or verification codes/numbers with the goal of creating or cracking account access to data or products. Examples include account creation, token cracking and credential cracking/stuffing. Nearly all of these attacks primarily target login pages.

The impact of account takeover? Fraudulent transactions, abuse of reward programs, and damage to brand reputation.

Advertising Traffic Fraud

Malicious bots create false impressions and generate illegitimate clicks on publishing sites and their mobile apps. In addition, website metrics, such as visits and conversions, are vulnerable to skewing. Bots pollute metrics, disrupt funnel analysis and inhibit key performance indicator (KPI) tracking. Automated traffic on your website also affects product metrics, campaign data and traffic analytics. Skewed analytics are a major hindrance to marketers who need reliable data for their decision-making processes.

[You may also like: Ad Fraud 101: How Cybercriminals Profit from Clicks]

The Business Opportunity for Service Providers

Regardless of the type of attack, service providers are typically held to high expectations when it comes to keeping customer data secure and maintaining service availability. With each attack, service providers risk customer loss, brand reputation, lost profits and at the worst, costly governmental involvement and the resulting investigations and lawsuits.

These same business expectations apply to service providers’ customers, many of whom require security services. Although large organizations can attempt to develop their own in-house bot management solutions, these companies do not necessarily have the time, money and expertise to build and maintain them.

Building an adaptive bot mitigation solution can take years of specialized development. Financially, it makes sense to minimize capex and purchase a cloud-based bot mitigation solution on a subscription basis. This can help companies realize the value of bot management without making a large upfront investment.

Lastly, this allows service providers to protect their core infrastructure and their own customers from bot-based cyberattacks and provides the opportunity to extend any bot management solution as part of a cloud security services offering to generate a new revenue stream.

2018 Mobile Carrier Ebook

Read “Creating a Secure Climate for your Customers” today.

Download Now

Application SecuritySecurity

How to Prevent Real-Time API Abuse

April 18, 2019 — by Radware1

API-abuse-960x640.jpg

The widespread adoption of mobile and IoT devices, and increased use of cloud systems are driving a major change in modern application architecture. Application Programming Interfaces (APIs) have emerged as the bridge to facilitate communication between different application architectures. However, with the widespread deployment of APIs, automated attacks on poorly protected APIs are mounting. Personally Identifiable Information (PII), payment card details, and business-critical services are at risk due to automated attacks on APIs.

API. application programming interface, cybersecurity, technology

So what are key API vulnerabilities, and how can you protect against API abuse?

Authentication Flaws

Many APIs only check authentication status, but not if the request is coming from a genuine user. Attackers exploit such flaws through various ways (including session hijacking and account aggregation) to imitate genuine API calls. Attackers also target APIs by reverse-engineering mobile apps to discover how it calls the API. If API keys are embedded into the app, this can result in an API breach. API keys should not be used alone for user authentication.

[You may also like: Are Your DevOps Your Biggest Security Risks?]

Lack of Robust Encryption

Many APIs lack robust encryptions between API client and API server. Attackers exploit such vulnerabilities through man-in-the-middle attacks. Attackers also intercept unencrypted or poorly protected API transactions between API client and API server to steal sensitive information or alter transaction data.

What’s more, the ubiquitous use of mobile devices, cloud systems, and microservice design patterns have further complicated API security as now multiple gateways are involved to facilitate interoperability among diverse web applications. The encryption of data flowing through all these channels is paramount.

[You may also like: HTTPS: The Myth of Secure Encrypted Traffic Exposed]

Business Logic Vulnerability

APIs are vulnerable to business logic abuse. Attackers make repeated and large-scale API calls on an application server or slow POST requests that result in denial of service. A DDoS attack on an API can result in massive disruption on a front-end web application.

Poor Endpoint Security

Most IoT devices and micro-service tools are programmed to communicate with their server through API channels. These devices authenticate themselves on API servers using client certificates. Hackers attempt to get control over an API from the IoT endpoint and if they succeed, they can easily re-sequence API order that can result in a data breach.

[You may also like: The Evolution of IoT Attacks]

How You Can Prevent API Abuse

A bot management solution that defends APIs against automated attacks and ensures that only genuine users have the ability to access APIs is paramount. When evaluating such a solution, consider whether it offers
broad attack detection and coverage, comprehensive reporting and analytics, and flexible deployment options.

Other steps you can (and should) take include:

  • Monitor and manage API calls coming from automated scripts (bots)
  • Drop primitive authentication
  • Implement measures to prevent API access by sophisticated human-like bots
  • Robust encryption is a must-have
  • Deploy token-based rate limiting equipped with features to limit API access based on the number of IPs, sessions, and tokens
  • Implement robust security on endpoints

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Cloud Security

Are Your DevOps Your Biggest Security Risks?

March 13, 2019 — by Eyal Arazi0

apikey-960x720.jpg

We have all heard the horror tales: a negligent (or uniformed) developer inadvertently exposes AWS API keys online, only for hackers to find those keys, penetrate the account and cause massive damage.

But how common, in practice, are these breaches? Are they a legitimate threat, or just an urban legend for sleep-deprived IT staff? And what, if anything, can be done against such exposure?

The Problem of API Access Key Exposure

The problem of AWS API access key exposure refers to incidents in which developer’s API access keys to AWS accounts and cloud resources are inadvertently exposed and found by hackers.

AWS – and most other infrastructure-as-as-service (IaaS) providers – provides direct access to tools and services via Application Programming Interfaces (APIs). Developers leverage such APIs to write automatic scripts to help them configure cloud-based resources. This helps developers and DevOps save much time in configuring cloud-hosted resources and automating the roll-out of new features and services.

[You may also like: Ensuring Data Privacy in Public Clouds]

In order to make sure that only authorized developers are able to access those resource and execute commands on them, API access keys are used to authenticate access. Only code containing authorized credentials will be able to connect and execute.

This Exposure Happens All the Time

The problem, however, is that such access keys are sometimes left in scripts or configuration files uploaded to third-party resources, such as GitHub. Hackers are fully aware of this, and run automated scans on such repositories, in order to discover unsecured keys. Once they locate such keys, hackers gain direct access to the exposed cloud environment, which they use for data theft, account takeover, and resource exploitation.

A very common use case is for hackers to access an unsuspecting cloud account and spin-up multiple computing instances in order to run crypto-mining activities. The hackers then pocket the mined cryptocurrency, while leaving the owner of the cloud account to foot the bill for the usage of computing resources.

[You may also like: The Rise in Cryptomining]

Examples, sadly, are abundant:

  • A Tesla developer uploaded code to GitHub which contained plain-text AWS API keys. As a result, hackers were able to compromise Tesla’s AWS account and use Tesla’s resource for crypto-mining.
  • WordPress developer Ryan Heller uploaded code to GitHub which accidentally contained a backup copy of the wp-config.php file, containing his AWS access keys. Within hours, this file was discovered by hackers, who spun up several hundred computing instances to mine cryptocurrency, resulting in $6,000 of AWS usage fees overnight.
  • A student taking a Ruby on Rails course on Udemy opened up a AWS S3 storage bucket as part of the course, and uploaded his code to GitHub as part of the course requirements. However, his code contained his AWS access keys, leading to over $3,000 of AWS charges within a day.
  • The founder of an internet startup uploaded code to GitHub containing API access keys. He realized his mistake within 5 minutes and removed those keys. However, that was enough time for automated bots to find his keys, access his account, spin up computing resources for crypto-mining and result in a $2,300 bill.
  • js published an npm code package in their code release containing access keys to their S3 storage buckets.

And the list goes on and on…

The problem is so widespread that Amazon even has a dedicated support page to tell developers what to do if they inadvertently expose their access keys.

How You Can Protect Yourself

One of the main drivers of cloud migration is the agility and flexibility that it offers organizations to speed-up roll-out of new services and reduce time-to-market. However, this agility and flexibility frequently comes at a cost to security. In the name of expediency and consumer demand, developers and DevOps may sometimes not take the necessary precautions to secure their environments or access credentials.

Such exposure can happen in a multitude of ways, including accidental exposure of scripts (such as uploading to GitHub), misconfiguration of cloud resources which contain such keys , compromise of 3rd party partners who have such credentials, exposure through client-side code which contains keys, targeted spear-phishing attacks against DevOps staff, and more.

[You may also like: Mitigating Cloud Attacks With Configuration Hardening]

Nonetheless, there are a number of key steps you can take to secure your cloud environment against such breaches:

Assume your credentials are exposed. There’s no way around this: Securing your credentials, as much as possible, is paramount. However, since credentials can leak in a number of ways, and from a multitude of sources, you should therefore assume your credentials are already exposed, or can become exposed in the future. Adopting this mindset will help you channel your efforts not (just) to limiting this exposure to begin with, but to how to limit the damage caused to your organization should this exposure occur.

Limit Permissions. As I pointed out earlier, one of the key benefits of migrating to the cloud is the agility and flexibility that cloud environments provide when it comes to deploying computing resources. However, this agility and flexibility frequently comes at a cost to security. Once such example is granting promiscuous permissions to users who shouldn’t have them. In the name of expediency, administrators frequently grant blanket permissions to users, so as to remove any hindrance to operations.

[You may also like: Excessive Permissions are Your #1 Cloud Threat]

The problem, however, is that most users never use most of the permissions they have granted, and probably don’t need them in the first place. This leads to a gaping security hole, since if any one of those users (or their access keys) should become compromised, attackers will be able to exploit those permissions to do significant damage. Therefore, limiting those permissions, according to the principle of least privileges, will greatly help to limit potential damage if (and when) such exposure occurs.

Early Detection is Critical. The final step is to implement measures which actively monitor user activity for any potentially malicious behavior. Such malicious behavior can be first-time API usage, access from unusual locations, access at unusual times, suspicious communication patterns, exposure of private assets to the world, and more. Implementing detection measures which look for such malicious behavior indicators, correlate them, and alert against potentially malicious activity will help ensure that hackers are discovered promptly, before they can do any significant damage.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

SecurityWAF

WAFs Should Do A Lot More Against Current Threats Than Covering OWASP Top 10

July 12, 2018 — by Ben Zilberman0

owasp-top-10-960x640.jpg

Looking in the rearview mirror

The application threat landscape has rapidly evolved. For years, users consumed applications over the internet using the common tool – web browsers. At every point in time, there were 2-5 web browsers to support, and the variety of application development and testing frameworks was relatively limited. For instance, almost all databases were built using the SQL language. Unfortunately, not long before hackers began to abuse applications in order to steal, delete and modify data. They could take advantage of applications in different ways, primarily by tricking the application user, injecting or remotely executing code. Shortly after, commercialized solutions named Web Application Firewalls (WAF) emerged, and the community responded by creating the Open Web Application Security Project (OWASP) to set and maintain standards and methodologies for secure applications.

Security

Another Problem I Face: Securing APIs in Continuous Delivery

July 26, 2017 — by Ben Zilberman0

api-security-960x643.jpg

The newly published OWASP Top 10 2017 Release Candidate introduces a new application security risk –protection of APIs.

It’s not a secret that managing information security is becoming more complex. It is also no secret that there are more threats and more solutions to stay on top of. While it makes me wonder if we are reaching the limit of the capabilities of the human mind when it gets to efficient information analysis for proper decision-making, I am quite certain we can agree that as far as information security professionals go, we are definitely getting to that point, subject to day-to-day constraints.