API Archives | Radware Blog

main

Threats on APIs and Mobile Applications

August 20, 2019 — by Pascal Geenens — 0

Web Application Programming Interfaces, or Web APIs, are essential building blocks of our digital lives. They provide the tools and protocols that enable web and mobile applications to provide dynamic content and up to date, personalized information.

Our cars, bikes, and fitness trackers rely on Web APIs to track and guide us to our personal goals. In our homes, digital personal assistants help us manage our schedules, control our home, play our music, and much more, and they do so by interacting with an API provided as a service in the cloud. Google Pay, Apple Pay, PayPal, and many others enable businesses around to globe to process customer payments by the press of a button or a swipe of their phone. Their APIs provide easy integration and increased security for online commercial businesses. Smart cities and Industry 4.0 are taking over the manufacturing world and allow new interconnected and automated manufacturing technologies and processes.

Cyber-physical systems monitor physical processes and make decentralized decisions based on a virtual model of the real world. Industrial Internet of Things (IoT) communicate and cooperate in real-time with users and across organizations.

These are only a few examples of the digital world we live in today and which relies on one very essential building block: the Web API.

What Are Web APIs?

A Web API is a set of tools and protocols that provide a predefined interface for a request and response messaging system between two programs. It exposes reliable content and provides operation negotiation through a common defined language. REST, short for REpresentational State Transfer, and the Simple Object Access Protocol (SOAP) are the most common protocol styles for cloud service architectures, with REST by far the most common one.

SOAP used to be the go-to messaging protocol that almost every web service used; it is a standardized protocol that allows the exchange of messages using underlying protocols such as HTTP, SMTP, TCP, UDP, and others. SOAP builds on a large number of frameworks using XML to format the messages. The standard includes a Web Services Description Language (WSDL) which defines the structure of the data in the message. SOAP is an official web standard with specifications maintained and developed by the World Wide Web Consortium (W3C).

As opposed to SOAP, REST is much less of a protocol and more of an architectural style. REST only provides a set of guidelines and allows much more flexibility in the implementation of the protocol by its developers. As such, the REST architecture gained much popularity and fitted better the agile and continuously evolving specs and requirements of modern-day web services.

The percentages of API Architectural Styles for profiles in the ProgrammableWeb API directory [source: https://www.programmableweb.com/news/which-api-types-and-architectural-styles-are-most-used/research/2017/11/26]

REST is used to build web services that are lightweight, scalable, and easy to maintain. Services build on the REST architecture are called RESTful services. The protocol underlying REST is HTTP, the most common and standardized web protocol supported by almost every system and device on the internet. Any program that can talk HTTP is a potential REST client, any system that can process HTTP requests can expose RESTful services. Talk the talk, walk the … ; meaning there needs to be an agreement between consumer and service for them to exchange actionable and useful information, hence the use of a common language such as XML or JSON.

REST requests and JSON structures are straightforward concepts. A request is very much like a URL with some arguments:

https://my.restservice.local/get_user?id=1

The response a webservice located at that URL could return might be a JSON formatted message. JSON is a human and machine readable format, very convenient and easy to find structure and derive meaning from the data by either humans and machines:

// JSON Object
{
“user”: {
“id”: 1,
“name”: “admin”,
“groupid”: 1,
“password”: “123456”
}
}

The API Economy

To create new online applications within acceptable time frames, one should try to use existing and proven components for repeating and basic tasks. Focusing on the development of the innovative and differentiating parts of the application and not wasting cycles on the commodity is how in-house development stays productive and commercially viable. The why of in-house development is mainly the innovation and differentiation of the application, or what makes it stand out in the crowd.

Most online applications rely on third-party and open source components, some of which could be Web APIs hosted in different clouds. Using third-party hosted Web APIs, developers can instantly add support for repeated and complex processes and do so in just a few lines of code. Using and consuming commercial-grade third-party APIs will typically not be free but is generally billed based on a subscription and number of (API) calls model, which embodies the ‘economy’ part of ‘the API economy.’

Credit card processing APIs are probably the most dominant component used by all commercial websites. It is more efficient and more secure to rely on a proven and certified third party to process customer payments. The security aspect and trust-worthiness of, say PayPal, results in much less resistance from visitors than to have them provide and store their credit card details on your website. Failing to provide an extensive list of payment options will negatively impact the success of your site. Think about how much more sales you could realize if your mobile app integrates with Apple and Google Pay and all your potential customer has to do is swipe from left to right to buy your products and services? No information or personal details to input, no additional authentication steps, all that is needed is a big smile for their phone to authorize the transaction and complete the purchase.

The Radware ShieldSquare Bot Manager relies on this very same Web API concept. Radware Bot Manager exposes a cloud-based service into which on-premise reverse proxies and web applications make API calls to differentiate legitimate users’ and good bot from bad bot requests. The service is provided to our customers as a subscription and pricing based on tiers of maximum number of API calls per month.

APIs, Built For and Consumed By Machines

APIs are by definition interfaces between machines. They are supposed to be consumed by devices and applications. Devices are machines, and their communication with the API is from and to machines (M2M). Mobile applications, dynamic web pages, or native user interface clients provide a graphical representation through which humans interact with the API. The graphical interface translates the interactions of the user into API requests while the data received in the API’s response message is rendered into a visual representation that makes more sense to the user.

Machines are good at processing structured data but have a harder time crunching through visual representations of that same data. Think about a paragraph in your document processor versus a scanned image of that same text. The visual representation of the text can be translated back to its original data representation, text in this case, but not without using complex tooling such as Optical Character Recognition (OCR) and only with a certain degree of success, most often not without introducing errors.

Do the exercise: this image provides tree representations of the same data. Which would you prefer to interact with and which do you think a machine would prefer? [data from https://opensource.adobe.com/Spry/samples/dataregion/JSONDataSetSample.html and formatted using http://json2table.com]_

Now put yourself in the shoes of an attacker that wants to scrape the product list from an online commercial website. Would you go at it by scraping and translating HTML pages and following links to discover and encode the full catalog? Or, would you first try to discover if an API feeds the dynamic content that gets rendered in the web browser? If you went for the latter, consider yourself a step closer to being a real hacker 😉

Securing Web APIs

The online nature of web APIs makes their communications subject to snooping or man-in-the-middle and replay attacks. Very much like the rest of the internet that is concerned about their privacy, all communication should be encrypted and origins verified. As REST relies on HTTP, SSL and TLS with certificates are the bare essentials.

Unless your Web API can verify the requesting client’s origin through a certificate, and as such leverages mutual TLS (mTLS), there is still no guarantee that the other side of the communication is a legitimate program with good intentions. Web APIs build on the same stateless paradigm and protocols used by web applications. While web applications are made stateful by introducing (hidden) session keys that get posted on each subsequent request after an initial login, Web API calls are by definition not stateful, but they can leverage the same ideas and concepts.

JSON Web Token (JWT), for example, is an open standard (RFC 7519) that defines a self-contained way for securely transmitting information between parties as a JSON object. The token is signed using a secret or a public/private key pair and as such, can be verified and trusted by a receiving service. Because of the self-contained nature of the token, authorization can be performed based on just the token, no need for resolving keys or tokens into actual identity.

For machine to machine communications, however, there is no interactive authentication step after which a session key or token gets generated. The way a consumer of a Web API can be authorized, is by using some kind of shared secret that was agreed upon upfront and that is shared with the API as one of the call request arguments. That secret would have been obtained through a separate authentication and authorization step. Many third-party Web API providers require the author of an application to register and request access to the API, at which point he or she will be provided with a personal access or API token. The API token identifies the client program and allows it to consume the API, while the providing service can authorize and track requests and utilization.

There are convenient APIs that provide authentication for third-party applications and can be leveraged by consumers and providers alike. Ever used your Google or Facebook account to get access to a service you never previously registered for? Applications and API providers can rely on a third party such as Google or Facebook, using them as a trusted middle-man to authenticate the consumer of the service. The consumer of the service can decide to trust the middle-man secures its private information and shares only what is agreed to and required for authorization with the provider’s service. The convenience brought to the consumer of the application is single-sign-on (SSO), meaning that the user only needs to register and login only once with Google and then can access and consume all the services and applications that rely on that middle-man. An example of such a standardized protocol is OAuth, also used by Google and Facebook in its 2.0 incarnation.

So I Secured My API. I’m Safe, Right?!

Not quite there yet, keep reading! Requests to Web APIs can be authenticated, authorized, and their contents protected by encryption.

However, what if you host a commercial website? Your definition of an authenticated user is that of a user that previously, in some cases just seconds ago, registered for access your website. Automated programs, commonly referred to as bots, are very much able to create email aliases, register as fictitious persons, process the email validation requests and get unlimited access to your website as do legitimate persons. A single request performed by a bot does not look any different than a request originating from a real human. Chaining multiple requests into an intended behavior; only then can one reveal the legitimate or malicious nature of the other party.

Some applications have the luxury of only servicing a limited number of consumers that can be vetted and certified through some clearance process – B2B applications typically. Even then, tokens can be compromised and unauthorized use of the API is still very much a possibility. Even if tokens are not directly compromised, client-side Cross-Site Request Forging (CSRF) and Server-Side Request Forging (SSRF) could allow malicious actors to abuse the API. Even when you have strict control on your API or host internal private APIs that are used only by your front-end servers, they are still at risk.

Mobile Apps, API Consumers With a Twist

Mobile applications are nothing more than fancy consumers of Web APIs. At least those applications that provide on-demand and data driven user experiences. Candy Crush probably not the most appropriate example, though a great user experience – no pun intended.

API requests are machine to machine and by consequence do not immediately reveal the presence of a natural person or the execution environment of the application. A web application’s environment can be challenged and identified using javascript injected into the application’s web pages. The content, application in this case, returned by a web server is dynamic and can be adapted on the fly or redirected if the need arises.

A mobile application, however, is static once delivered and installed and relies on API calls to only update that portion of the representation that contains dynamic information. Unless the mobile application includes functionality that allows it to identify human behavior through motion sensors or click and swipe patterns, and it can certify it is running on a real device and not in an emulated environment, the back end APIs cannot verify the actual state of the application.

By nature, mobile applications are publicly accessible and can easily be reversed to reveal their inner working. Reversing mobile applications uncovers the specific API calls directly following user actions such as clicks (or presses), as well as any embedded static tokens or certificates which provide the keys to the API kingdom.

Furthermore, easy access to device emulation software such as QEMU allows anyone to run the application in thousands of virtual instances and perform automated actions such as advertisement clicks which can cost you dearly.

Conclusions

Securing your web APIs and ensuring legitimate use of them requires more than authentication and authorization. Even if you are sure that your application is coded with best security practices, your infrastructure is top-notch secured and audited, and the application contains no vulnerabilities, there is still the threat of automated attacks that leverage legitimate requests to build a chain of behavior that results in malicious activity. Each individual request is legitimate, but the end game of the thousands of bots disguised as legitimate users could be a depleted stock or information being processed and leveraged competitively against you.

Building web APIs for B2B, providing customers with Mobile Apps, etc. increases customer loyalty, prevents customer churn, and increases revenue and competitiveness. However, these same APIs and mobile applications can be turned into a weapon against your business, and in a very insidious way, without immediate indication something or someone malicious is at work. A bot management solution should be considered when exposing APIs that are directly or indirectly connected with your business and revenue.

For those aware that applications without vulnerabilities are RBUs, consider the added layer of protection provided by a Web Application Firewall that will prevent abuse of vulnerable code and infrastructure, and it will even protect you from Cross-Site and Server Side Request Forgery.

Read “The Ultimate Guide to Bot Management” to learn more.

Download Now

4 Emerging Challenges in Securing Modern Applications

May 1, 2019 — by Radware — 0

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.

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.

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.

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.

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

Bot Management: A Business Opportunity for Service Providers

April 30, 2019 — by Radware — 0

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.

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.

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.

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.

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.

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.

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.

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

Download Now

How to Prevent Real-Time API Abuse

April 18, 2019 — by Radware — 1

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.

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.

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.

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

Are Your DevOps Your Biggest Security Risks?

March 13, 2019 — by Eyal Arazi — 0

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.

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.

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 3^rdparty partners who have such credentials, exposure through client-side code which contains keys, targeted spear-phishing attacks against DevOps staff, and more.

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.

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

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

July 12, 2018 — by Ben Zilberman — 0

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.

Another Problem I Face: Securing APIs in Continuous Delivery

July 26, 2017 — by Ben Zilberman — 0

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.

main

What Are Web APIs?

The API Economy

APIs, Built For and Consumed By Machines

Securing Web APIs

So I Secured My API. I’m Safe, Right?!

Mobile Apps, API Consumers With a Twist

Conclusions

Read “The Ultimate Guide to Bot Management” to learn more.

Share this:

The WAF Ten Commandments

Challenge 1: Bot Management

Challenge 2: Securing APIs

Challenge 3: Denial of Service

Challenge 4: Continuous Security

Protecting All Applications

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

Share this:

Bot Traffic in the Service Provider Network

Protecting Core Application from Bot Access

API Exposure

Account Takeover

Advertising Traffic Fraud

The Business Opportunity for Service Providers

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

Share this:

Authentication Flaws

Lack of Robust Encryption

Business Logic Vulnerability

Poor Endpoint Security

How You Can Prevent API Abuse

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

Share this:

The Problem of API Access Key Exposure

This Exposure Happens All the Time

How You Can Protect Yourself

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

Share this:

Looking in the rearview mirror

Share this:

Share this: