No CAPTCHA - URL is not yet qualified for challenge injection
Hi, I am setting up Brute Force protection in ASM and have noted that I can get this drop traffic and alert, but when attempting to show the CAPTCHA, I only get the blocking page we have configured. The help notes that this occurs when theURL is not yet qualified for challenge injection, but the help also provides no details how to correct this. Can anyone assist? Assuming ASM policy: PolicyX and url: /LoginHere.aspx Thank you
What causes the TSbd/TSbp script to be inserted into the source code of a website?
In the source code of the website I work on I see that the script below is being inserted. <script type="text/javascript"> //<![CDATA[ window["_tsbp_"] = { ba : "X-TS-BP-Action", bh : "X-TS-AJAX-Request"}; //]]> </script><script type="text/javascript" src="/TSbd/08300f25d2ab20002940ca95b1a84050e4ba6d156f677a6f2819bde419b59b20e8b36a05eca4b390?type=2"></script> As we have AMP pages on our website which doesn't allow any custom JavaScript we would like to not get this script inserted. However, we are having some problems indentifying what exactly is causing this script to be inserted. We do run the WAF on our F5 and I suspect it's the culprit but I have been unable to confirm this. Also, I've been moving around some elements in the <head> tags and when I specifically move our scripts down to the bottom the TSbd/TSbp script is no longer being inserted. What I would like to know is what triggers the TSbd/TSbp script to be inserted. I am starting to think something on the F5 looks at the first X bytes of the page and then decides whether or not to insert the script. I would also like to know if there is more information about this topic available as I've not been able to find a lot. Maybe I am just not searching for the correct thing.
SEC7111 HTTP Security Compromised Generated by a JavaScript.
Hey everyone! I just ran into an issue that I haven't seen before. Let me give you some background: We have a backend web application running only on port 80 and publish this through a standard HTTPS virtual server using only a Client SSL Profile. We have also a HTTP to HTTPS VS to make sure we access the site over HTTPS. Everything is working great except for a specific function on the site. The application is used to handle internal billing and once you are done with entering your details, you can print a report. When working correctly, this should open up the report as a PDF file in a new window. This is when things go south. Apparently there is a JavaScript that helps creating this PDF file. First we get the "Internet Explorer is not showing all of the content". When accepting that we get nothing. When checking the debugging you find this: The JavaScript is generating a URL of http:// when we have an active session running on https:// and security is being jeopardized. When going to the exact URL that reports the error but changing it to https:// it works straight away. So I know what the problem is but I have no idea how to fix it. Long term would be to turn on HTTPS on the back-end server but that will take some time and we need a fix for this quite fast since they cannot print out these reports if they are not in the local office, connecting to the server directly. I tried searching through the JavaScript to see if I can find where it actually uses http:// and just using a Stream Profile change it but I have not found anything. I also tried to add a Stream Profile changing Source: http://[URL] to Target: https://[URL] but that bricked the site. Since the problem is the JavaScript, the browser won't even send the request to the F5. If it were to send the request to the F5 it would hit the iRule and get redirected to HTTPS. Do you guys have any idea?
Snippet #7: OWASP Useful HTTP Headers
If you develop and deploy web applications then security is on your mind. When I want to understand a web security topic I go to OWASP.org, a community dedicated to enabling the world to create trustworthy web applications. One of my favorite OWASP wiki pages is the list of useful HTTP headers. This page lists a few HTTP headers which, when added to the HTTP responses of an app, enhances its security practically for free. Let’s examine the list… These headers can be added without concern that they affect application behavior: X-XSS-Protection Forces the enabling of cross-site scripting protection in the browser (useful when the protection may have been disabled) X-Content-Type-Options Prevents browsers from treating a response differently than the Content-Type header indicates These headers may need some consideration before implementing: Public-Key-Pins Helps avoid *-in-the-middle attacks using forged certificates Strict-Transport-Security Enforces the used of HTTPS in your application, covered in some depth by Andrew Jenkins X-Frame-Options / Frame-Options Used to avoid "clickjacking", but can break an application; usually you want this Content-Security-Policy / X-Content-Security-Policy / X-Webkit-CSP Provides a policy for how the browser renders an app, aimed at avoiding XSS Content-Security-Policy-Report-Only Similar to CSP above, but only reports, no enforcement Here is a script that incorporates three of the above headers, which are generally safe to add to any application: And that's it: About 20 lines of code to add 100 more bytes to the total HTTP response, and enhanced enhanced application security! Go get your own FREE license and try it today!
Javascript REST API proxy with HTML UI, nodeJS and iControl module
Problem this snippet solves: 1) Provides browser interface to REST API. 2) Provides an all javascript inclusive app for managing BigIP objects. Enable/Disable/Add/Edit pool members. Only pool members for now. 3) Provides an API proxy via the use of Node.JS . Most scripts require an application or the CLI to launch or to integrate with. This app offers a GUI interface, in many ways similar to the BigIP GUI, rendered by a browser and served by Node. NodeJS connects to the BigIP and creates the dynamic pages which are rendered by browser. With NodeJS coming soon to the BigIP, this app could be installed on and served by the BigIP. How to use this snippet: Uses iControl proxy module from github, https://github.com/thwi/node-icontrol First Install node.js on one of your machines from: https://nodejs.org Next install the icontrol module: npm install icontrol To run this: 1) copy snippet and save to file: e.g. bigip_rest_proxy.js 2) start node: node bigip_rest_proxy.js <<This will start a web server listening on 8080 3) Securely Browse to https://ip_address_of_machine_ running_node:8080 This should work for 11.5 but I have only tested it in 11.6. Also Note that the credentials for the bigip are hard-coded for now. Sorry. To put your own, go ahead and change them inside the 'connect' function, lines 180-181. Code : 61606 Tested this on version: 11.6
Web UI Tweaks for version 12
Hi! I've just released the new Web UI Tweaks for v12 in case someone want's to try: https://devcentral.f5.com/codeshare/webui-tweaks-v12-1109 Feedback very much welcome! Here's a list of what it does: Pool improvements Pool list member statuses When the pools contains one available member the status is still green today. This script shows you icons depending on what different statuses a pool contains. If all members are disabled, the color is black. If the pool contains both available and members being down, the circle is half green, half red. Pool details on mouse over Hovering the mouse over a status icon shows the member details: Custom loading screen Got a big partition so the statuses takes a while to load? No problem, the script will let you know when it's finished. Default options when creating a pool Pool name suffix, action on service down, load balancing method, and select node node instead of creating a new one can be pre-populated for you by editing the configuration. Automatically generated monitor tests Test strings for browser, curl and netcat commands are generated automatically for http monitors. iRule improvements Detecting data group lists The when editing an iRule the script will detect the used data group lists and show them on the left hand side. Hovering the mouse over a data group list name will show it's content. Clicking on it will take you to that data group lists configuration form. Data group list improvements No more accidentally deleting data group list records If you use data group lists as much as we do there's a chance that you have encountered this scenario. You need to edit a record, so you click on the "Edit" button, change the entries and then click on update. Ooops, now that record was deleted. Instead, the script would disable the edit button after clicking on it. It won't be enabled again until either after you click add, or when you clear the text in the input fields. Bulk import The script allows you to do bulk edits to your data group lists. Merge the lists: Takes all the records in the import text area, compares them to the active list and imports the records that does not have duplicate keys. This means that if "apple" := "banana" exists in the active list and the import list has "apple" := "banana", then "apple" := "banana" won't be imported. Replace the current list: Takes all the records in the import text area and replaces the active list. Duplicate records are ignored like with "Merge the lists". Edit active list: Moves all the records from the active list to the import list. Client SSL Profile improvements Automatically match SSL Client profile name, certificate and key When creating an SSL profile the script will attempt to find a matching certificate and key according to the name of the profile. So when you click on on the add button in the Client SSL Profile form you'd get everything automatically populated for you (providing that you have configured the default chain in the script). SSL CSR improvements Pre-populated profiles for creating certificate signing requests. Other small things Larger select fields when ie. choosing monitors, editing data group lists. Mark objects in the current partition with bold text to distinguish them from the common partition. Adds a link to the default pool in the virtual server resources configuration page. (Patrik
F5 APM Login Page Reload Attempts Username Evaluation
I am working on a tricky F5 Issue. While trying to port a custom HTML page from Microsoft TMG to F5 BIG-IP APM, I have come across a behavior on the F5 that I would like to mitigate. This particular custom HTML page requires that there is a link that inserts a cookie and reloads the page. This function happens in JavaScript. When the page reloads the F5 logs and entry for Username ''. After 3 reloads APM reaches Max Failed Login Attempts and displays "Your session could not be established." The first question I have is why is authentication attempted before the Form Submit button is pressed? JavaScript, Cookie, Page Reload: When the link is pressed a cookie is inserted and the page a location.reload() is invoked. Cookie Evaluation: The presence of the cookie loads an alternate CSS file, and the location.reload() allows the page to load with the new CSS file. This allows for a different logo and color scheme to be applied. When the link is pressed a 2nd time, the cookie is removed, the page is reloaded, and the default CSS file is applied. Is it possible to prevent the F5 from evaluating form data when the page is reloaded? Would it be possible to redirect the user back to the login page and reset the number of login attempts?A Billion More Laughs: The JavaScript hack that acts like an XML attack
Don is off in Lowell working on a project with our ARX folks so I was working late last night (finishing my daily read of the Internet) and ended up reading Scott Hanselman's discussion of threads versus processes in Chrome and IE8. It was a great read, if you like that kind of thing (I do), and it does a great job of digging into some of the RAMifications (pun intended) of the new programmatic models for both browsers. But this isn't about processes or threads, it's about an interesting comment that caught my eye: This will make IE8 Beta 2 unresponsive .. t = document.getElementById("test"); while(true) { t.innerHTML += "a"; } What really grabbed my attention is that this little snippet of code is so eerily similar to the XML "Billion Laughs" exploit, in which an entity is expanded recursively for, well, forever and essentially causes a DoS attack on whatever system (browser, server) was attempting to parse the document. What makes scripts like this scary is that many forums and blogs that are less vehement about disallowing HTML and script can be easily exploited by a code snippet like this, which could cause the browser of all users viewing the infected post to essentially "lock up". This is one of the reasons why IE8 and Chrome moved to a more segregated tabbed model, with each tab basically its own process rather than a thread - to prevent corruption in one from affecting others. But given the comment this doesn't seem to be the case with IE8 (there's no indication Chrome was tested with this code, so whether it handles the situation or not is still to be discovered). This is likely because it's not a corruption, it's valid JavaScript. It just happens to be consuming large quantities of memory very quickly and not giving the other processes in other tabs in IE8 a chance to execute. The reason the JavaScript version was so intriguing was that it's nearly impossible to stop. The XML version can be easily detected and prevented by an XML firewall and most modern XML parsers can be configured to stop parsing and thus prevent the document from wreaking havoc on a system. But this JavaScript version is much more difficult to detect and thus prevent because it's code and thus not confined to a specific format with specific syntactical attributes. I can think of about 20 different versions of this script - all valid and all of them different enough to make pattern matching or regular expressions useless for detection. And I'm no evil genius, so you can bet there are many more. The best option for addressing this problem? Disable scripts. The conundrum is that disabling scripts can cause many, many sites to become unusable because they are taking advantage of AJAX functionality, which requires...yup, scripts. You can certainly enable scripts only on specific sites you trust (which is likely what most security folks would suggest should be default behavior anyway) but that's a PITA and the very users we're trying to protect aren't likely to take the time to do this - or even understand why it's necessary. With the increasing dependence upon scripting to provide functionality for RIAs (Rich Interactive Applications) we're going to have to figure out how to address this problem, and address it soon. Eliminating scripting is not an option, and a default deny policy (essentially whitelisting) is unrealistic. Perhaps it's time for signed scripts to make a comeback.Working around client-side limitations on custom HTTP headers
One of the most well-kept secrets in technology is the extensibility of HTTP. It's one of the reasons it became the de facto application transport protocol and it was instrumental in getting SOAP off the ground before SOAP 1.2 and WS-I Basic Profile made the requirement for the SOAP Action header obsolete. Web browsers aren't capable of adding custom HTTP headers on their own; that functionality comes from the use of client-side scripting languages such as JavaScript or VBScript. Other RIA (Rich Internet Applications) client platforms such as Adobe AIR and Flash are also capable of adding HTTP headers, though both have limitations on which (if any) custom headers you can use. There are valid reasons for wanting to set a custom header. The most common use of custom HTTP headers is to preserve in some way the source IP address of the client for logging purposes in a load-balanced environment using the X-Forwarded-For custom header. Custom HTTP headers can be set by the client or set by the server or intermediary (load-balancer, application delivery controller, cache) as well and often are to indicate that the content has passed through a proxy. A quick perusal of the web shows developers desiring to use custom HTTP headers for a variety of reasons including security, SSO (single sign on) functionality, and to transfer data between pages/applications. Unfortunately, a class of vulnerabilities known as "HTTP header injection" often causes platform providers like Adobe to limit or completely remove the ability to manipulate HTTP headers on the client. And adding custom headers using JavaScript or VBScript may require modification of the application and relies on the user allowing scripts to run in the first place, the consistency of which can no longer be relied upon. But what if you really need those custom headers to either address a problem or enable some functionality? All is not lost; you can generally use an intelligent proxy-based load balancer (application delivery controller) to insert the headers for you.If the load balancer/application delivery controller has the ability to inspect requests and modify the requests and responses with a technology like iRules, you can easily add your custom headers at the intermediary without losing the functionality desired or needing to change the request method from GET to POST, as some have done to get around these limitations. Using your load balancer/application delivery controller to insert, delete, or modify custom HTTP headers has other advantages as well: You don't need to modify the client or the server-side application or script that served the client The load balancer can add the required custom HTTP header(s) for all applications at one time in one place Your application will still work even if the client disables scripting Custom HTTP headers are often used for valid reasons when developing applications. The inability to manipulate them easily on the client can interfere with the development lifecycle and make it more difficult to address vulnerabilities and quirks with packaged applications and the platforms on which applications are often deployed. Taking advantage of more advanced features available in modern load balancers/application delivery controllers makes implementing such workarounds simple.
APM Disable JavaScript Patching
I want to disable JavaScript Patching from a portal access resource. The web site contains JavaScripts using AJAX (There are no links content in JavaScript code). The web site should fully function after disabling JavaScript Patching. I know that there is a need to enable JavaScript Patching for some of the links (XMLHttpRequests,*.JS) How can I know which links I need to patch ? Many Thanks for answer !
