network-side scripting
There are 40 entries for the tag network-side scripting
#mobileThe expansive options consumers revel in creates an identity crisis for IT that is best resolved via context-aware mobile mediation. Back in the days of the browser wars, when standards were still largely ignored and the battle for the desktop was highly competitive, developers had to make choices and compromises. They could either write extensive client-side scripts to detect the user’s browser and address the peculiarities of that environment or they could simply ignore them with a disclaimer that “this site (works best when viewed in | was written for) browser X.” As time...
posted @ Monday, January 16, 2012 5:00 AM | >
Application delivery infrastructure can be a valuable partner in architecting solutions …. AJAX and JSON have changed the way in which we architect applications, especially with respect to their ascendancy to rule the realm of integration, i.e. the API. Policies are generally focused on the URI, which has effectively become the exposed interface to any given application function. It’s REST-ful, it’s service-oriented, and it works well. Because we’ve taken to leveraging the URI as a basic building block, as the entry-point into an application, it affords the opportunity to optimize architectures and make more efficient the...
posted @ Wednesday, October 12, 2011 4:31 AM | >
Cookies as a service enabled via infrastructure services provide an opportunity to improve your operational posture. Fellow DevCentral blogger Robert Haynes posted a great look at a UK law regarding cookies. Back in May a new law went info effect regarding “how cookies and other “cookie-like” objects are stored on users’ devices.” If you haven’t heard about it, don’t panic – there’s a one-year grace period before enforcement begins and those £500 000 fines are being handed out. The clock is ticking, however. What do the new regulations say? Well essentially whereas cookies...
posted @ Wednesday, September 14, 2011 3:04 AM | >
It’s not enough to have a strategic point of control; you’ve got to use it, too. One of the primary threats to the positive operational posture of an organization is that of extremely heavy load. Whether it’s from a concerted effort to take down the site (DDoS) or simply an unanticipated flood of legitimate users is really not as important to today’s discussion as understanding the impact both can have not just on your applications, but on their supporting infrastructure. You know, the network “stuff” that sits between the client and your applications, defending...
posted @ Friday, April 01, 2011 3:32 AM | >
Use network-side scripting, of course!
While just about every developer and information security professional knows that a buffer-overflow exploit can result in the execution of malicious code not many truly grok the “why”. Fortunately, it’s not really necessary for either one to be able to walk through the execution stack and trace the byte-code as it overwrites registers and then jumps to execute it. They know it’s A Very Bad Thing™ and perhaps more importantly they know how to stop it.
SECONDARY and TERTIARY DEFENSE REQUIRED
The best place to prevent a buffer-overflow vulnerability is in the application code. Never...
posted @ Monday, December 27, 2010 6:17 AM | >
The fallacy of security is that simplicity or availability of the solution has anything to do with time to resolution The announcement of the discovery of a way in which an old vulnerability might be exploited gained a lot of attention because of the potential impact on Web 2.0 and social networking sites that rely upon OAuth and OpenId, both of which use affected libraries. What was more interesting to me, however, was the admission by developers that the “fix” for this vulnerability would take only “six lines of code”, essentially implying a “quick fix.” ...
posted @ Wednesday, August 11, 2010 3:58 AM | >
Exorcising your digital demons
Most people are familiar with Shakespeare’s The Tragedy of Macbeth. Of particularly common usage is the famous line uttered repeatedly by Lady Macbeth, “Out, damn’d spot! Out, I say” as she tries to wash imaginary bloodstains from her hands, wracked with the guilt of the many murders of innocent men, women, and children she and her husband have committed.
It might be no surprise to find a similar situation in the datacenter, late at night. With the background of humming servers and cozily blinking lights shedding a soft glow upon the floor, you might hear...
posted @ Wednesday, July 14, 2010 3:53 AM | >
The grab bag of awesome that is network-side scripting is, in general, often overlooked. Generally speaking “network gear” isn’t flexible, nor is it adaptable, and it certainly isn’t extensible. But when you put network-side scripting into the mix, suddenly what was inflexible and static becomes extensible and dynamic. In many cases if you’ve ever said “I wish that thing could do X” well, in the case of application delivery it probably can – you just have to learn how. The how, in the case of F5, is iRules. iRules is network-side scripting, so...
posted @ Friday, July 02, 2010 6:46 AM | >
Minimizing the impact of code changes on multi-tenant applications requires a little devops “magic” and a broader architectural strategy
Ignoring the unavoidable “cloud outage” hysteria that accompanies any Web 2.0 application outage today, there’s been some very interesting analysis of how WordPress – and other multi-tenant Web 2.0 applications – can avoid a similar mistake. One such suggestion is the use of a “feathered release schedule”, which is really just a controlled roll-out of a new codebase as a means to minimize the impact of an error. We’d call this “fault isolation” in data center architecture 101. It turns out...
posted @ Monday, June 14, 2010 4:03 AM | >
Options to put a stop to the latest mutation of the Pushdo trojan The Pushdo bot is a malevolent little beast that is nothing new to Infosec professionals. What might be new, however, is that it recently changed its code and now creates junk SSL connections. Lots of them. I mean you are likely seeing an unexpected increase in traffic by several million hits spread out across several hundred thousand IP addresses. No you didn't read that wrong that is millions of hits and hundreds of thousands of IP addresses. This...
posted @ Tuesday, March 23, 2010 3:13 AM | >
The W3C specification now offers the means by which cross-origin AJAX requests can be achieved. Leveraging network and application network services in conjunction with application-specific logic improves security of allowing cross-domain requests and has some hidden efficiency benefits, too. The latest version of the W3C working draft on “Cross-Origin Resource Sharing” lays out the means by which a developer can use XMLHTTPRequest (in Firefox) or XDomainRequest (in IE8) to make cross-site requests. As is often the case, the solution is implemented by extending HTTP headers, which makes the specification completely backwards and cross-platform compatible even if the...
posted @ Tuesday, February 09, 2010 4:18 AM | >
Using HTTP headers and default browser protocol handlers provides an opportunity to rediscover the usability and simplicity of the mailto protocol.
Over the last decade it's become unsafe to use the mailto protocol on a website due to e-mail harvesters and web scraping. No one wants to put their e-mail address out on teh Internets because two minutes after doing so you end up on a trillion SPAM lists and the next thing you know you're changing your e-mail address.
But people still wanted to share contact information, so it became common practice to spell out your e-mail address, such...
posted @ Thursday, January 28, 2010 3:07 AM | >
I haven’t heard the term “graceful degradation” in a long time, but as we continue to push the limits of data centers and our budgets to provide capacity it’s a concept we need to revisit. You might have heard that Twitter was down (again) last week. What you might not have heard (or read) is some interesting crunchy bits about how Twitter attempts to maintain availability by degrading capabilities gracefully when services are over capacity. “Twitter Down, Overwhelmed by Whales” from Data Center Knowledge offered up the juicy details: ...
posted @ Wednesday, January 27, 2010 2:55 AM | >
Cloud computing and content delivery networks (CDN) are both good ways to assist in improving capacity in the face of sudden, high demand for specific content but require preparation and incur operational and often capital expenditures. How about an option that’s free, instead? While it’s certainly in the best interests of every organization to have a well-thought out application delivery strategy for addressing the various events that can result in downtime for web applications it may be that once in a while a simple, tactical solution will suffice. Even if you’re load balancing already (and you are, of...
posted @ Monday, January 25, 2010 3:55 AM | >
An interesting thing happens when you combine toolkits like XAJAX and SAJAX and the ability to perform content-based routing: you can actually achieve function-level load balancing in both cloud-based and traditional architectures. As you might have discovered from previous posts mentioning it, I still do web application development to support hobby interests in my (very little) spare time. I’m currently in love with the XAJAX library, which has made development of what is supposed to be a very interactive application nearly effortless. I’m also very much enamored of load balancing/application delivery and cloud computing, specifically...
posted @ Wednesday, December 09, 2009 3:59 AM | >
The long, lost application delivery spell compendium has been found! Its once hidden, arcane knowledge is slowly being translated for the good of all web applications. Luckily, you don’t have to be Elminster or Gandalf or <insert powerful wizard you know here> to cast this spell over your infrastructure Contingency School of Magic: Evocation Components: Somatic (requires gestures), Material (requires physical component) Saving Throw: None Spell Resistance: No Through the use of the contingency spell, application delivery professionals can dictate the conditions...
posted @ Monday, December 07, 2009 3:37 AM | >
Using Anonymous Human Authentication to prevent illegitimate access to sites, services, and applications. In the “real world” there are generally accepted standards set for access to a business and its services. One of the most common standards is “No shirt, no shoes, no service.” Folks not meeting this criteria are typically not allowed past the doors of a business. But on the web, access to services is implicit in the fact that the business is offering the service. If the HTTP service is accessible, it’s implicitly allowing connections and providing service without any standard criteria...
posted @ Monday, November 30, 2009 4:47 AM | >
If you aren’t using all the security tools at your disposal you’re doing it wrong. How many times have you seen an employee wave on by a customer when the “security device enclosed” in some item – be it DVD, CD, or clothing – sets off the alarm at the doors? Just a few weeks ago I heard one young lady explain the alarm away with “it must have be the CD I bought at the last place I was at…” This apparently satisfied the young man at the doors who nodded and turned back to whatever...
posted @ Thursday, November 19, 2009 3:42 AM | >
Yesterday the blogosphere, twittosphere, and other-spheres were abuzz when a new TLS renegotiation man-in-the-middle attack was disclosed.
Interestingly enough, while we were all still reading about it and figuring out all the nuances, one of our own DevCentral members was out implementing a solution.
No, he’s not a vendor with a product to worry about, he’s just a “guy” trying to defend his web site and applications from potential attacks like this one. But he’s a guy with network-side scripting in his arsenal of web application security tools, and with that and his understanding of the very well-documented vulnerability...
posted @ Friday, November 06, 2009 12:30 PM | >
You can address the problem of converting smart quotes – and any other content - in your application if you control the code. What if you’re using third-party software for which you do not have the code? Or what if it is your code but the “defect” is so low on the priority list that you won’t get to it until the year 2020?
Dealing with Microsoft smart quotes is a fact of life for developers. Almost every developer out there has a server-side script/function they use to strip them out of user-generated content and replace them with web-friendly HTML...
posted @ Monday, November 02, 2009 3:03 AM | >
One of the benefits of Infrastructure 2.0 is connectedness: the ability to collect and share pertinent data regarding the health and performance of applications and infrastructure services. Based on that data a dynamic infrastructure can adapt on-demand and make decisions that respect real capacity limits, not artificial ones. Randy Hayes writes “The CapCal Blog”, and describes CapCal as being about “measuring the performance and scalability of web apps using real, production level workloads.” In A Very Delicate Load Balancing Act he discusses the impact of load balancing configurations on the capacity and performance of applications. ...
posted @ Wednesday, October 14, 2009 4:20 AM | >
Cloud offers an appealing “pay only for what you use” that makes it hard to resist. Paying on a per-usage hour basis sounds like a good deal, until you realize that your site is pretty much “always on” because of bots, miscreants, and users. In other words, you’re paying for 24x7x365 usage, baby, and that’s going to add up. Ironically, the answer to this problem is … cloud. Don and I occasionally discuss how much longer we should actually run applications on our own hardware. After all, the applications we’re running are generally pretty light-weight, and only see...
posted @ Tuesday, October 13, 2009 4:30 AM | >
Steve (apparently yes, we are on a first name basis) offers up his thoughts on developing APIs for the Cloud in “A Cloud Tools Manifesto.” While the inclusion of the word “manifesto” in the title raised quite the stir (“Manifestogate” is still fresh on the minds of many cloud-oriented people), what really caught my eye is his inclusion of a “mock endpoint” primarily for testing of API based integration and development. This is something that’s increasingly important not just to cloud but to Web 2.0 and social networking sites that provide APIs via which other sites and client applications can...
posted @ Monday, October 05, 2009 4:00 AM | >
There are few things in reality that can match The Gazebo in its ability to evoke fear and suspicion amongst gamers. The links on your web site may be one of them. In the history of Dungeons and Dragons there exists the urban legend known to all as “The Gazebo.” The Gazebo, over the years, has become a gaming euphemism for a situation in which people over analyze and overestimate the risk involved with interacting with some “thing”. In the case of The Gazebo the “thing” was, as you might guess, a gazebo. Yes, a simple wooden...
posted @ Thursday, October 01, 2009 4:07 AM | >
AJAX enables the use of network-side scripting enabled application delivery solutions to offload client-side functionality and improve capacity and performance of dynamic (Web 2.0/AJAX) applications. In the last couple of weeks I’ve embarked on a home project to rewrite – from scratch – a couple of web applications that Don and I and friends use on a regular basis. Consider it a very restricted (in terms of users) social networking application, because that’s basically what it is. I made heavy use of AJAX for one component in the past version but have been really leveraging it a lot more...
posted @ Wednesday, September 16, 2009 5:02 AM | >
Notice that isn’t a question, it’s a statement of fact Twitter is having a bad month. After it was blamed, albeit incorrectly, for a breach leading to the disclosure of both personal and corporate information via Google’s GMail and Apps, its apparent willingness to allow anyone and everyone access to a .htaccess file ostensibly protecting search.twitter.com made the rounds via, ironically, Twitter. This vulnerability at first glance appears fairly innocuous, until you realize just how much information can be placed in an .htaccess file that could have been exposed by this technical configuration faux...
posted @ Tuesday, July 21, 2009 3:28 AM | >
The “replace” in “rip and replace” essentially means getting rid of old security problems and replacing them with new ones. Twittergate is (thankfully) behind us but it’s almost assuredly going to be the case that we’ll be rehashing this one for a while. This certainly isn’t the first time Twitter and security issues have clashed, and as in the past Twitter (and really any very public application in a similar situation) is the clear loser. And of course there comes the unsolicited advice offered regarding what Twitter needs to do to address its security issues. I am, of...
posted @ Monday, July 20, 2009 3:43 AM | >
One of the interesting points that discussions around intercloud brings up is the need for infrastructure to, if you’ll pardon the use of marketing jargon, align with the business. What that really means is that applications and their supporting infrastructure need to be more business-aware. Thing is you don’t really need intercloud or even cloud or even virtualization for many of these business-aware capabilities. They are certainly a boon, but solutions that include application delivery functionality don’t need to wait for a fully-baked cloud or intercloud implementation. Consider, for example, the potential of business-layer load...
posted @ Wednesday, July 15, 2009 3:55 AM | >
But browser support is only half the solution, don’t forget to implement the server-side, too. Clickjacking, unlike more well-known (and understood) web application vulnerabilities, has been given scant amount of attention despite its risks and its usage. Earlier this year, for example, it was used as an attack on Twitter, but never really discussed as being a clickjacking attack. Maybe because aside from rewriting applications to prevent CSRF (adding nonces and validation of the same to every page) or adding framekillers there just haven’t been many other options to prevent the attack technique from being utilized against...
posted @ Tuesday, June 23, 2009 3:27 AM | >
One of the tasks of an enterprise architect is to design a framework atop which developers can implement and deploy applications consistently and easily. The consistency is important for internal business continuity and reuse; common objects, operations, and processes can be reused across applications to make development and integration with other applications and systems easier. Architects also often decide where functionality resides and design the base application infrastructure framework. Application server, identity management, messaging, and integration are all often a part of such architecture designs. Rarely does the architect concern him/herself with the network infrastructure, as that is...
posted @ Wednesday, June 17, 2009 4:07 AM | >
Making the case for a Hungarian Notation variation for URL hierarchies One of the top discussions out in the ether these days revolves around URL shortening. One of the reasons folks flock to URL shortening services like bit.ly and TinyURL is because web sites and applications use exceedingly long URLs. Many times this is because of exposed file system hierarchies (a potential security risk, by the way) and a desire to take advantage of descriptive file names for SEO and informational reasons. Recently Delicious founder Joshua Schachter expressed his opinion that URL Shorteners are bad for the web, while...
posted @ Monday, April 06, 2009 3:15 AM | >
Ah, those were the days, weren’t they? When improving the security, reliability, and performance of applications over the LAN, over the WAN, and over the Internet meant you had to deploy many different solutions, each one standing on their own in the data center. When you had to learn how to configure and manage as many devices as you have fingers just to deliver a single business-critical application to users and customers across a wide variety of environments. When there really wasn’t an option because solutions weren’t unified, weren’t contextually aware, and were basically just a bunch of point solutions...
posted @ Monday, March 23, 2009 3:21 AM | >
Ah, those were the days, weren’t they? When you needed a way to add security at several layers to your network and application network infrastructure but knew that implementing a solution capable of securing those pesky applications was more than likely going to end up with poor performance and angry users. When you needed to add something to secure applications and the network against the growing wave of attacks but knew that doing so would negatively impact performance. It was a tough choice, and most people ended up going the route of maintaining application performance at the expense...
posted @ Monday, March 16, 2009 3:39 AM | >
Ah, those were the days, weren’t they? When you needed a way to inspect data at the edge for application-specific issues but knew that implementing a solution capable of that kind of agility was more than likely going to end up with poor performance and angry users. When you needed to add something to secure applications and the network against the growing wave of attacks but knew that doing so would negatively impact performance. It was a tough choice, and most people ended up going the route of maintaining application performance at the expense of security and optimization...
posted @ Monday, March 09, 2009 4:30 AM | >
One of the ways miscreants locate targets for mass SQL injection attacks that can leave your applications and data tainted with malware and malicious scripts is to simply seek out sites based on file extensions. Attackers know that .ASP and .PHP files are more often than not vulnerable to SQL injection attacks, and thus use Google and other search engines to seek out these target-rich environments by extension. Using a non-standard extension will not eliminate the risk of being targeted by a mass SQL injection attack, but it can significantly reduce the possibility because your site will automatically turn...
posted @ Thursday, March 05, 2009 3:46 AM | >
Owning the stack is important to security, but it’s also integral to a lot of other application delivery functions. And in some cases, it’s downright necessary. Hoff rants with his usual finesse in a recent posting with which I could not agree more. Not only does he point out the wrongness of equating SaaS with “The Cloud”, but points out the importance of “owning the stack” to security. Those that have control/ownership over the entire stack naturally have the opportunity for much tighter control over the "security" of their offerings. Why? because they...
posted @ Wednesday, February 25, 2009 3:13 AM | >
Zero-day IE exploits and general mass SQL injection attacks often overshadow potentially more dangerous exploits targeting lesser known applications and attack vectors. These exploits are potentially more dangerous because once proven through a successful attack on these lesser known applications they can rapidly be adapted to exploit more common web applications, and no one is specifically concentrating on preventing them because they're, well, not so obvious.
Recently, SANS Internet Storm Center featured a write up on attempts to exploit Roundcube Webmail via the HTTP Accept header. Such an attack is generally focused on exploitation of operating system, language, or environmental...
posted @ Thursday, January 15, 2009 9:12 AM | >
Over the holidays Marcin @ tssci security offered up a python script for brute forcing the HTTP OPTIONS on directories. One of the reasons someone would want this information is because if you're (accidentally, of course) allowing PUT methods on any directories, someone can upload something nasty and potentially execute an attack. The availability of PUT makes XSS attacks simple even for script kiddies, for example. There may be legitimate reasons for enabling PUT on your servers, but you don't necessarily want the whole world to know that - just the applications that need the functionality....
posted @ Monday, January 05, 2009 5:58 AM | >
You may recall a recent overview on network-side scripting that described a few uses of this technology integrated with application delivery controllers. With thousands of examples of the uses of network-side scripting it's hard to choose just one to adequately represent its potential. Luckily, we don't have to stick to just one. Viva la Internet! Based on the technical session the great network-side scripting guru Colin and I ran at SD Best Practices in October, I've pulled nine ways to use network-side scripting that can enhance the scalability, security, and performance of web applications into a presentation for...
posted @ Thursday, December 11, 2008 4:04 AM | >
Horizontal scalability achieved through the implementation of a load balancing solution is easy. It's vertical scalability that's always been and remains difficult to achieve, and it's even more important in a cloud computing or virtualized environment because now it can hurt you where it counts: the bottom line. Horizontal scalability is the ability of an application to be scaled up to meet demand through replication and the distribution of requests across a pool or farm of servers. It's the traditional load balanced model, and it's an integral component of cloud computing environments. Vertical scalability is the ability of...
posted @ Tuesday, November 25, 2008 3:29 AM | >