Javascript
There are 14 entries for the tag Javascript
Detecting bots requires more than a simple USER_AGENT check today… Anyone who’s taken an artificial intelligence class in college or grad school knows all about the Turing Test. If you aren’t familiar with the concept, it was a “test proposed by Alan Turing in his 1950 paper Computing Machinery and Intelligence, which opens with the words: "I propose to consider the question, 'Can machines think?'" Traditional Turing Tests always involve three players, and the goal is to fool a human interviewer such that the interviewer cannot determine which of the two players is human and which...
A recent tweet about a free, Linux-based XML Security suite reminded me that we do not opine on the subject of XML security and its importance enough. SOA has certainly been dethroned as the technology darling du jour by cloud computing and virtualization and with that forced abdication has unfortunately also come a reduction in the focus on XML and security. That’s particularly disturbing when you recognize that what’s replaced SOA – primarily WOA and RESTful APIs – exchange data primarily via one of two formats: XML and JSON. Whether you prefer one over the other is...
Google didn’t kill HTTP. Neither did Colonel Mustard or Professor Plum. In fact, HTTP is still very much alive. Okay, folks, it’s time to stop declaring the death of protocols/technologies prematurely. Please? Especially when such proclamations are clearly not representative of reality. From ElasticVapor :: Life in the Cloud In Google's announcement what I found most fascinating was the protocol they choose for the basis of their new realtime vision. It wasn't HTTP but instead XMPP was selected as the foundation for this decentralized and interoperable vision. What this means in...
The webification of applications over the years has led to the belief that client-server as an architecture is dying. But very few beliefs about architecture have been further from the truth. The belief that client-server was dying - or at least falling out of favor - was primarily due to fact that early browser technology was used only as a presentation mechanism. The browser did not execute application logic, did not participate in application logic, and acted more or less like a television: smart enough to know how to display data but not smart enough to do anything...
As an application delivery solution provider focused on securing, accelerating, and optimizing web applications, we pay a lot of attention to web application development trends. Languages, environments, and technologies are all of significant interest because in many cases the decisions regarding development affect the security and performance of applications deployed in production. AJAX-based applications, for example, can have a significant impact on performance of the application and on the network (and vice-versa), so we pay attention to its adoption and use and are always looking for new ways to secure and accelerate applications using the technology. ...
We all understand the lines in the sand (or the architectural diagram) that separate client-side scripting from server-side scripting. It's very clear that client-side scripting, e.g. JavaScript, VBScript, ActionScript, executes on the client while server-side scripting, e.g. PHP, ASP, executes on the server. But what about network-side scripting?
"There is no such thing!" might be the first response to this question, but I beg to disagree. Programmable proxies, a la F5's BIG-IP Local Traffic Manager, that provide a scripting language such as iRules, are simultaneously client-side and server-side, with the best definition to describe their placement in architectures being network-side...
After proclaiming very publicly that I loved HttpFox and everyone Related Posts should have it there were many comments regarding Firebug, including some that came via e-mail. I've used Firebug in the past, but hadn't really looked at it in comparison to HttpFox and thought that with so many people saying it was "all that and more" with regards to HttpFox, I should...
The discussion yesterday on JavaScript and security got me thinking about why it is that there are no good options other than script management add-ons like NoScript for securing JavaScript. In a compiled language there may be multiple ways to write a loop, but the underlying object code generated is the same. A loop is a loop, regardless of how it's represented in the language. Security products that insert...
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: ...
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...
By now you've certainly heard about the "zero day" Adobe Flash player exploit. If not, you can read a bit about it here and here. What appears to be going on is similar to how other exploits and malware become quickly propagated across the web: Set up a site that hosts some malware with a simple but effective password stealer hidden in a Flash file Inject malicious code via SQL injection techniques into a web site that will load the Flash files from the host you set up in step 1....
Diving more deeply into the issue of speeding up JavaScript and the load balancing question, Scott Conroy points out: The single URL strategy has a major downside, though it is certainly cleaner than having to deal with many URLs. Since HTTP 1.1 says that user agents and servers SHOULD have only two concurrent connections, requests for multiple resources can easily develop into blocking operations. If, say, I have a page that includes twenty images to download, my browser (in its default config) will only download 2 images at a time. If I put those images on multiple "servers"...
Over the past few weeks we've examined the issues inherent with Web 2.0 and in particular AJAX-based applications. These issues need to be dealt with, but they should not be considered "show stoppers" to moving ahead with your Web 2.0 initiative. Consider the security ramifications of the design, implementation, and deployment of your new application carefully. Build security into your new application up front and you'll certainly be able to decrease the potential risks associated with this growing technology. Consider the following methods to CUT the RISK associated with deploying Web 2.0 applications: •Check VA tools for AJAX...
This is Part 3 of a series on Web 2.0 Security.
A good way to remember things is to use mnemonics, so when you're trying to list the security issues relevant to Web 2.0 just remember this: it's a MASHup.
More of everything.
Asymmetric data formats
Scripting based
Hidden URLs and code
This episode is brought to you by the letter "S".
Scripting-based
Web 2.0 technologies, specifically AJAX, are based on the execution of scripts. As we mentioned in Part I of...
