hackademix.net

References:

• about:robots
• Gort! Klaatu barada nikto!

What is Database Connectivity for JavaScript?

IBM® Database Connectivity for JavaScript™ is middleware that enables Web clients to directly access server-side relational data without compromising enterprise security.

“Directly access” without compromising “enterprise security”, yeah…

On the client, IBM Database Connectivity for JavaScript consists of a JavaScript API and library that can be used by Web applications without special browser plug-ins. On the server, the IBM Database Connectivity for JavaScript gateway, written in PHP, is an adaptor layer that mediates between IBM Database Connectivity for JavaScript and relational databases and provides functions such as operation forwarding and security. Web 2.0 applications can thus use IBM Database Connectivity for JavaScript to access relational data as a first-class construct instead of through ad hoc protocols.

Before you start wondering (like I did) what “operation forwarding” and “security” mean in this context, I’ll tell you since I bothered to read the source code: it’s just a thin layer with a JDBC-like API which allows JavaScript code to compose and submit SQL statements from the client side!
Security, if any, needs to be enforced at the database level, and access credentials are sent from the client side as well.

IBM Database Connectivity for JavaScript supports the trend for Web applications to be dynamically composed in a Web browser — so-called “Web 2.0″ applications — instead of being completely composed on the server (”Web 1.0″).

First “enterprise”, now “Web 2.0″…

IBM Database Connectivity for JavaScript is specifically geared toward enabling the potential Web 2.0 benefits of increased application responsiveness and the ability to flexibly combine information from various sources on the client. Web 2.0 access to server-side data, however, is currently characterized by Representational State Transfer (REST)-like APIs, which are typically application specific.

Bah, those old-fashioned resource mappings which (try to) expose only the data subsets relevant to the application front-end…
But now we can unleash the full power of SQL: free queries to all our databases for everyone in the fantastic world of Web 2.0!

ODBC is powerful — allowing any SQL statement to be executed — and simple, in the sense that developers are required to understand only a few abstractions. IBM Database Connectivity for JavaScript can be thought of as an “ODBC for Web clients,” enabling Web developers to benefit from a general-purpose API for accessing relational data.

Great work IBM! Now please convince some of your many banking customers to deploy this fantastic technology on their Internet-facing web servers, and we’ll be happy to “benefit from a general purpose API for accessing relational data” directly from Firebug, thanks!

Looks like I’m helping Obama’s campaign in an unexpected way :)

Update

Let’s help Google doing its part too: John McCain, John McCain, John McCain, John McCain, John McCain, John McCain, John McCain, John McCain, John McCain…

If you’re a FlashBlock user, you may feel outraged by being brutally rickrolled this way, but you need to know that it could happen at any moment.

No special trick, just a Youtube movie embedding through a plain <object> HTML element. Examine the source code if you don’t believe it:

<object width="300" height="242" data="http://youtube.com/v/A3_n0B1EaOY"> </object>

Not a big deal, really, if you consider FlashBlock a “noise reducer”: it does a great job, in facts, working almost always.

A bit more worrisome, though, if you used to believe FlashBlock could improve your security against Flash vulnerabilities. Your next surprise video star may be way more malicious than Trojan.SWF.Astley…

To be fair, you would be in good company:

• Slashdot, whose “flashblock” tag is attached to all the most recent Flash security horror stories
• US-CERT (United States Computer Emergency Readiness Team)
• F-Secure, the antivirus company
• Dancho Danchev, renowned security expert and Zero Day ZDNet blogger

If they just looked at FlashBlock’s FAQ, they would have found that the word “security” is never mentioned: a testament both to the good faith of the developers, who honestly advertise FlashBlock as an excellent annoyance blocker rather than a security enhancement, and to the superficiality of some advices.

Dancho is especially inexcusable, since he’s the only one forgetting to mention NoScript, which features similar flash-blocking capabilities but, being developed with security as its main focus, is immune from this and other possible circumventions and, more important, would regard even the most exotic unblockable edge case as a serious bug to be fixed as soon as possible.

Oops, I couldn’t block my own rant :)

A couple of months ago, Brandon Sterne of the Mozilla Security Team asked me some questions about NoScript’s internals, because he was developing a Firefox add-on which involved selective script-blocking.

Looks like he finally delivered: Site Security Policy is a proof of concept for an idea proposed by RSnake and turned into a specification by Gervase Markham, known as “Content Restrictions”.

A Site Security Policy is defined by the website administrator and communicated to the web browser as a set of special “X-SSP-…” HTTP headers either attached to the affected content or sent in response to a “discovery” HEAD request:

• X-SSP-Script-Source specifies a deny/allow list of hosts which are allowed to run scripts.
  If this header is sent, no embedded script is allowed to run, and only included scripts whose sources match the rules are executed. This is an effective anti-XSS countermeasure, and could be extremely useful for so called “Web 2.0″ sites featuring user-generated rich content.
• X-SSP-Request-Source lists the hosts which can or cannot send HTTP requests to a certain resource, and the “acceptable” HTTP verbs.
  This can help enforcing referrer-based checks against CSRF attacks which work even if user chooses to omit or spoof the Referer header for privacy reasons, and mitigating verb-tampering attacks when used to “enhance” CSRF.
• X-SSP-Request-Target limits the destinations of requests originated by the current page.
  This may help mitigating data-leakage outcomes of a successful XSS attack, e.g. by preventing authentication tokens from being logged to remote hosts, but also avoiding the page to be used as a platform for CSRF attacks and blocking inclusion of unwanted 3rd party content.
• X-SSP-Report-URI declares an URL where policy violation attempts should be logged by the browser.

If you want to start applying these restrictions to your web content, you’ll find a detailed yet simple reference with examples on Brandon’s project web site.
Implementing a Site Security Policy cannot surrogate web developers’ security awareness and best practices, but it’s nonetheless a big step forward in making a website safer for its users.

Obviously enough, to be generally effective this technology still needs to be evangelized to administrators and coders, correctly deployed and supported in a consistent cross-browser fashion. But as soon as it gets built in our favourite browser and we begin to see badges like “Browsing this site is safer with Firefox”, we can hope other vendors to join making the Web a safer place.