These articles are about technology, and its effects of security and privacy. Sometimes I post exploits that I find here, other times I warn of issues and possible exploits. I'm not malicious! Merely curious...
Its been two years since my inaugural blog post on April 29th, 2006: The Trouble With RSS. Over my site's second year, I wanted to do some long-term analysis on how different web analytics tools track hits, visits, and the like. As expected, they don't agree with each other:
Curious about why web site statistics differ based on the tool? SiteMeter uses an embedded image (at the bottom of this page), and tracks a hit every time somebody loads the image... so if you block banner ads, your visit might not be recorded. Google Analytics loads some JavaScript, which is useful for tracking more complete data... but if your browser blocks JavaScript (or cross-domain JavaScript), it wont register a hit. I found it odd that SiteMeter tracked more visits, but fewer hits than Google Analytics... curious.
In contrast with the other two, Webalizer uses raw Apache logs to determine hit count, so it tracks every single dang hit... Over 3 million hits in one year??? That's clearly too many... I'm not that interesting... but the visit count might be more accurate. Webalizer is the only analytics tool that tracks folks who view my site with RSS Readers, which may hit my site several times per day... thus the higher visit count. The hit count is hyper inflated because it counts search engine spiders, spammers, and hack attempts (some better than others).
All told, if the majority of folks view my site with RSS, then Webalizer's count is more accurate. If most of them view it the old fashioned way, then the other two are more accurate. I'm probably in the 100,000 - 200,000 visits per year range.
Unfortunately, none of these numbers include the folks who read my site through an online RSS readers, like Google Reader, or Bloglines. These sites hit my RSS feed once, then share it with dozens of folks who subscribe to the feed... To get a better estimate, I could pipe my RSS Feed through something like Feedburner. Feedburner keeps track of how many subscribers you have on the online feed readers, and produces decent stats on it... however, once you move your feed to Feedburner, its almost impossible to move it out... so I'm not happy with that option. Even so, that still wouldn't track those who view my content through RSS aggregators like Central Standard Tech, or Orana, or other sites that run Planet.
Well, what about the data from Alexa? That site ranks web pages based on those who surf the web with a toolbar that tracks their every move. Personally, I think people who surf with that toolbar are opening up a major security hole... so their viewing audience is probably restricted to folks who are kind of tech savvy, but don't take security precautions. In other words, newbie geeks. I've never broken into the top 100,000 sites ranked on Alexa, but I frequently break the top 100,000 sites ranked by Technorati... although Technorati only ranks blogs.
Even if we could accurately count how many people hit the site, we're still at a loss to know who paid attention. Google Analytics tries to measure "time on the page", other metrics include bounce rate, or even the number of comments.
Oh well... A reliable measure of relevance will always be elusive... but at least we have enough estimates to support a cottage industry of people analyzing those metrics to prove anything they are told to prove ;-).
Back to my anniversary... Lots of stuff has changed since my first anniversary post: I've traveled to South Africa, Brazil, and Argentina... I've remodeled my kitchen, I've nearly completed my second book on Oracle enterprise content management, I've given technology presentations at Oracle Open World, AIIM Minnesota, BarCamp Minnesota, and IOUG Collaborate in Denver. I've trained both salespeople and consultants on what Enterprise Content Management actually is, and I helped negotiate a settlement to an 18-month lawsuit against a local non-profit. Oh yeah... I implemented about a dozen ECM solutions as well...
Next year, I hope to have even more goin' on... and a few more web site visits.
When I first heard about Oracle taking a new direction with their old content management product -- meaning the old Content DB, not the newly acquired Stellent stuff -- the first thing I thought was it's about time!
When Oracle claimed it had 2 content management systems, that really confused people... especially considering that Content DB was at best a set of tools to create a content management system, whereas Stellent was a full blown application plus framework. They really weren't like each other at all.
Universal Online Archive (UOA) is Content DB, but now focused on being an archiving platform. On Oracle 11g, it is an extension on the Secure Files feature of the database. If you haven't heard of Secure Files yet, it beats the Linux filesystem on both read and write performance. It also has compression, de-duplication (only storing duplicate files once), and encryption. The encryption is an extension of Oracle Transparent Data Encryption, plus support for encrypting entire tablespaces instead of just individual columns. This means support for foreign keys, as well as indexes beyond the basic b-tree stuff...
Compression reduces the storage needs by 33% on average, according to Oracle. If you then use the statistics from IDC that there are 8 copies for every 1 content item, then de-duplication would bring to total storage down by 87.5%... all while maintaining better-than-filesystem performance, despite the added cost of encryption. See this whitepaper for some tuning statistics and tips.
Secure Files is the next generation of Large Objects for the database... and it's very cool... but what should you run on top of it? For the longest time, the folks at Stellent balked at using the database for file storage. Using the filesystem made much more sense because of performance reasons, which made up for the additional complexity of the architecture. However, if the user has 11g, there really is no better option than storing content items in the database.
NOTE: This rule-of-thumb does not apply for web content -- especially for small images and thumbnails. In those cases, a split approach where public web assets are stored locally would probably be faster. Luckily, a customized FileStoreProvider can help you achieve this.
Also, Oracle Universal Online Archive finally fits in with Oracle's broader strategy for content management. Even though it can store anything, the first release will have connectors to email servers to be a mail archive:
This fits right in with the Universal Records Management strategy, which is to embed a Records Management Agent in remote repositories, and control their life cycle from the Records Management system.
In other words, your email archiving policy is no longer dictated by IT. Your records managers can say when an item should be archived, and how long it should be retained based on events, instead of simply time and size constraints. For example, emails should be retained 2 years after a project completion, 6 months after employee termination, or 12 months after you lose a specific customer. That will reduce both your email space requirements, and your legal risk.
But it doesn't stop there... the next step is to make connectors to other content management systems, for example, Sharepoint. The idea is to archive content out of systems like Sharepoint, and replace them with a "stub". When a user downloads from Sharepoint, the "stub" is smart enough to redirect the download to the archive, and return it directly.
In other words, you could be using a secure, compressed, de-duplicated, encrypted, archive without ever noticing. Throw in a Records Management Agent, and you'll also invisibly comply with dozens of regulation and laws... no matter where you store your information.
Its a good strategy, and some interesting technology... we'll see how it pans out.
UPDATE: The release was announced, but they don't have a date for when it will be available for download. Here's some more info about the release, and some places to watch for downloads:
Hat tip Reddit:
http://www.google.com/search?q=inurl:SELECT+inurl:FROM+inurl:WHERE+intitle:phpmyadmin
Almost 1000 hits... yikes. Trust me, its funny (and sad) if you know SQL injection...

After my security posts last week (here, here, and here), I got an interesting email from an Oracle partner out west (David Roe from Ironworks)... one of his customers put Stellent though a battery of automated security tests, and got some surprising results:
Incidentally one of our clients ran through a couple rounds of automated security testing on their UCM instance. They sort of surprised us with it actually, but when they were done sent back some great feedback about how strong the system was and how it passed every check (apparently an uncommon occurrence). I personally don't put a lot of faith in any automated testing, but it's nice to know Stellent will pass one :)
Like the author, I don't put that much faith in automated tests... but many of these security testing companies are batting 1000: some of these firms brag that they always find security holes, but this time they came up empty. Even on an unannounced, surprise, security audit.
Naturally, neither David no myself will reveal the name of the customer... because bragging about an unbreakable system is the surest way to attract the wrong attention... but if a legitimate analyst or existing Oracle customer would like to chat with these folks, Dave could facilitate a connection.
On April 1st, Google announced that their Google Docs application now works offline.
This is kind of the direction that people have been taking for a while... being able to use Rich Internet Application technology like Adobe AIR to work on web forms, but take them offline for later viewing. However, Google decided to take an oddly different approach.
They decided to use Google Gears, which is a combination of a browser plug-in, a mini web server, and a SQL database. You don't need to use Java or Flash in order to save data to the database, you just use standard JavaScript calls.
Its like AJAX on crack. And if done right, it could break down even more walled gardens than Web 2.0 did.
Currently, Google Gears is only in its 0.2 release: very very very beta. Not like GMail beta, or Google Docs beta... but so beta that maybe they should call it alpha or something. What I found interesting was the possible effect this strategy will have on the rest of Google's applications. Take Spreadsheets offline? How about my Analytics data? Why not GMail? The process would be this:
Now... What happens when you add Greasemonkey to the mix?
Greasemonkey is a popular little application that allows you to inject custom HTML and JavaScript into other people's web sites. Do you want an extra link on the home page to take you directly to the latest news? No problem. Don't like the way GMail organizes its buttons? Re-arrange them. Hate the look and feel of a site? Use a custom stylesheet.
Don't like how GMail organizes its back-end data store? Well, too bad, you can't use Greasemonkey to force GMail to store or retrieve your data differently... that is, unless Gmail uses Gears!
If so, I could inject custom code to not only synchronize with my online database, but store it however I want. Previously, Greasemonkey could only access existing content -- provided it was available through AJAX or Remote Scripting. But when combined with Gears, Greasemonkey scripts can perform radical analysis of web content, and store the processed information locally! It can also synchronize back to the main site, for proper online storage...
In effect, Greasemonkey allows end users to inject customized code for web page display... but Greasemonkey plus Gears allows you to inject a whole custom web application! So what??? Well, imagine being able to do this:
Naturally... the security risks are profound... If Gears ever got popular, a little JavaScript on an evil site could read much more than just your cookies... So its important to lock down the ability for one site to read another site's database. However, we should probably relax access for things like cross-site Greasemonkey, otherwise we'll miss out on most of the value of Gears.
Will it bring about the next gen of the web? Web 3.0? Web 4.5? Maybe web candle plus monkey? We'll see what happens in Gears 0.3...
UPDATE: Jake had the suggestion that it might be more useful to use Mozilla Prism with Greasemonkey, as opposed to Google Gears. Lifehacker recently profiled Prism. That depends on how this plays out... Prism would work great for Firefox-based rich internet apps... whereas Adobe AIR and Google Gears would be more cross-platform. If you want iPhone support, you'll need Safari. Although at present Prism is more feature complete than Gears.
Overall, I think Google Gears is going in a better direction than AIR or Prism, because they are following the maxim don't break the web!... but time will tell if they can actually deliver.
James responds... to my latest security rant, with a lot of good points. I think this point here is the best:
Have you ever noodled that as data flows from one system to another within an SOA, but the security model doesn't, that this is another attack vector? For example, what if I have access to data in a policy administration system such that I can figure out if you are insuring an auto that your wife doesn't know about but couldn't do the same in a claims administration system? I bet you can envision scenarios when you integrate a BPM engine with an ECM engine that security becomes weaker.
Absolutely... unfortunately, this is an amazingly difficult problem. Its not really the realm of ECM or BPM to solve it... rather, the best thing that we can do is not get in the way. Let the experts solve that one, and then integrate as well as possible with global policy management systems.
My suggestion is this:
Most applications in the Oracle ECM stack follow this methodology... but I can't vouch for all Oracle applications. I like it, because its flexible enough to 'slave' yourself to an identity management system, and yet still have some local control over access rights if you want to 'boost' somebody's credentials.
I think it would be great if Oracle chose to augment this model to add support for a policy auditing standard... but I have no idea if anybody is asking for one, and if so, which one? I'm positive James has an opinion... I'm a fan of just using Business Intelligence to do the reporting, since (again) you can "sneak-in" better security along with the latest buzzword ;-)
Sub-optimal? Of course... but anything that makes security look less like a cost-center is good...
I also like the concept of Oracle's magic black box for identity services. That would make it easier for developers to create policy-based security models, that (in theory) would work with old, new, and emerging standards alike (XACML, CardSpace, OpenID, etc.). It's not that I don't like XACML, its simply that there are other horses in this race... and developers do not have the power to dictate architecture. We can suggest what works best, but in the end, the most sellable product will support them all.
I fully agree that #4 is a possible attack vector, which is why good access auditing and rights auditing tools are important... However, users frequently insist on local control of security rights, because there are many legitimate business cases where it isn't feasible to place all users in a global repository with the proper rights. Sometimes -- especially during mergers and acquisitions -- you want to keep the identities and access rights of these folks as secret as possible. Or, if your IT department has a 3-week waiting period for new users, but you need a contractor NOW for a 2 week project, guess what will happen?
I especially like how Oracle ECM implements #3... some of the more interesting aspects of the future of security involve multiple challenges for access. For example, assume a user has access to both mundane and highly restricted content, but her daily work is usually with the mundane. Now, at 7pm, she's suddenly accessing a ton of highly restricted content. Red flag! Even if her security tokens have not yet expired, a good security system would notice that this behavior is strange, and demand further authentication credentials... maybe the name of her first pet, or the manual-override PIN.
Anyway, Oracle ECM doesn't do any integrations like that as of yet, but it has the flexibility to do it... several identity management systems support that approach, and ECM is being positioned more and more as "infrastructure..." so I'd wager its only a matter of time.
I don't mind when James throws daggers at me about security... because
Seriously, I believe we agree on several points... we just have different perspectives.
My point was that creating secure software is extremely difficult... even if you educate your developers about the OWASP top ten (which ain't all that great anyway), and even if you religiously use tools like Ounce Labs or Coverity, you'll always have problems. Those tricks are good checks against developers making brain dead stupid decisions, but they'll never catch the subtler security problems.
The issue is one of complexity... the vast majority of security holes occur in the interfaces between applications and/or concerns. This doesn't just mean cross-site scripting vulnerabilities on the web interface, nor just the sql-injection attacks on the back end... it also includes any time you connect two code bases together in new and novel ways. The very nature of service-oriented architectures and modular code bases exponentially increases the number of things that can go wrong. Even a security-savvy developer that runs Coverity would never have enough time to test every possible permutation... nobody is willing to wait that long for the test cycle to complete, nor would anybody be willing to pay for it.
Thus, some problems will never be noticed until they are "in the wild."
You can yell and scream all you want... but this doesn't change the basic math. Again, don't just listen to me... check out security guru Bruce Schneier and his essay on why insecure products will always win in the marketplace. Its basic economics, called the "market for lemons," which I've covered before.
James seems to need some kind of evidence that the code is at least reasonably safe before putting it into production. Fair enough, but his suggestions suck. I can't think of one single certification that I would be personally willing to trust... penetration tests are OK but flawed. Developer certification courses only teach the basics, and are generally useless. Stamps of approval by "security experts" are nice, but as I've mentioned before, I've found problems that these self proclaimed "experts" missed.
In short, all of James's proposed solutions are false senses of security. Rely on them at your peril. If he's got a new one I've missed, I'm all ears.
You will always need to patch your applications. Accept it. You will never have a "100% secure" system. Accept it. The best you can hope for is something that gets more and more "defensible" as it matures. Accept it. Patches are a necessary evil. Accept it.
Instead of fighting the security battle -- which you will never win -- pick a battle that will both make your life easier, and have better security as a byproduct. Demand that your vendor:
That's probably the best you can hope for...
UPDATE: James responds, and I continue the dialog.
Do you use Stellent, or any Oracle technology? Then you should probably take the IOUG Oracle Security Survey:
Select the OSSA Security Survey, and let 'er rip! It's sponsored by Oracle and the Independent Oracle Users Group. The goal is to gather information about your security practices including general processes for vulnerability and patch management, Critical Patch Updates, and the like. IOUG will analyze the results, and issue recommendations to Oracle at Oracle's next Security Customer Advisory Council. IOUG has release a security podcast to explain more about the survey.
I was shocked to discover that fewer than 20% of Oracle customers admit to applying the rolling security patches that Oracle releases... yikes. Back when I was a developer, I always found it extremely frustrating that customers rarely applied patches to known security holes... CERT often says that 99% of security breaches are due to users not applying patches. In other words, 80% of Oracle customers choose to make themselves vulnerable to 99% of the attacks.
WHY???
Unlike James McGovern, I don't believe security problems are entirely due to bad software or clueless developers... I'd argue most security problems are due to improperly configured and improperly maintained software. However, I also believe that blaming the implementation team is a cop-out. Instead, developers need to realize that security is a process, not a product (hat tip Schneier).
Thus, the best thing a developer can do for security is focus on software that can effortlessly evolve to meet tomorrow's security challenges. If you want secure applications, first demand software that is effortless to patch and maintain. This includes software that can easily roll-back patches in case the security fix broke something important... Then fewer people would fear installing the patches, more would use the existing patches, and there would be significantly fewer breaches.
If software were easy to configure and maintain, then security would get better and better the longer you owned it... not to mention you'd have fewer bugs, and generally better software. Stable products are always more secure. Why? If the product is rock solid, with few bugs, then people are less risk-averse to applying critical patches. Better documentation helps as well, as do better patch tools...
With easy patching, easy maintainability, stable software, and a vigilant community, security is a natural by-product. Also, this helps security becomes less of a cost-center... easy patching and configuration is great for ROI, no matter what.
It Just Makes Sense©, so don't expect too many people to press for it any time soon...
Although relatively speaking, I'm pretty impressed with Oracle's patch technology. The new 11g database watches for errors, and can notify you about patches that might fix the problem. Likewise, the Content Management team has a pretty good patch process... unfortunately, it takes forever to get anything out to Metalink, so your best bet is to always contact support for the latest patches.
Its true... why not leave a comment?
Holy cow... you should see the rants and raves against the TSA's liquid ban! Pure. White. Hatred.
I don't know what their angle is... maybe they know that most of their processes are silly, and they'd like to prove that there's a strong desire for change. Maybe they'd like to lift the liquid ban, but still be able to cover their ass, as Bruce Schneier would say... or maybe they're looking to expand their "no-fly list".
I understand people's frustration with the TSA: being a frequent traveler, I'm often a victim to their Kafka-esque rules... but some of these comments are unbelievably hostile. Cut the TSA some slack, give some constructive criticism, and maybe they'll stand up for common sense security... which after the past seven years, would be a breath of fresh air.
(Hat Tip Al Kamen)
Bruce Schneier is one of the most insightful people in computer security... he knows the encryption algorithms and protocols like the back of his hand, and he's also fundamentally aware of the human problem. That's why he's so eminently quotable... and his talk at DefCon 15 didn't disappoint:
http://video.google.com/videoplay?docid=-1672905904171732325
He talks about how broken airline security is, including how to fly without your ID... new hash functions, new encryption standards, voting, side-channel attacks, laptop security, and why you should never trust your anti-virus company.
The best quote: Data is the pollution problem of the information age. Classic...
How we dispose or deal of this data after we're done is how we will be judged in the future. Orwell got it wrong: its not about real-time surveillance, its about leaving a data trail that can be mined. Unlike Germany, in the US data about you is not owned by you...
I'm not as paranoid about the loss of privacy, as I've mentioned before... as data pollution becomes the status quo, and everybody's embarrassing profile is online, we're going to need more tolerance to hold society together... Intolerant groups and corporations will wither and die, either from sex scandals, or lack of innovation. I see that as a good thing.
Naturally, this gets more complicated when dealing with medical history or military secrets... but you get the point.
Nishant Kaushik has another good post on Identity management... this time talking more about Identity as a service. People should make it brain dead easy for developers to integrate enterprise identity management into your applications, regardless of which system you use. He also linked to his presentation. I liked it a lot... I think its a great idea... but something about it gave me a chuckle.
At present, there are at least nine identity "standards": CardSpace, LDAP, OpenID, SXIP, SAML, SPML, WS-*, XACML, XDAS... not to mention basic username/password authentication, custom modules, and proprietary systems like SiteMinder. And even the most commonly used standards are a pain to develop with.
The solution -- which I fully support -- appears to be to wrap all the "standards" in a functional, proprietary API. Then you only need to know one API, and have one repository, for all your identity management needs.
Makes you wonder why people bother to call them "standard," doesn't it?
I remember three years ago at Stellent, Sam White was so fed up with so many security standards, he sketched out a version of the Content Server that did nothing but authentication and authorization services. A bit ahead of its time, because it took till now for the market to beg for something like this.
Anyway, good luck to Nishant...
UPDATE: Gerald Beuchelt is upset because my list above isn't exhaustive, it mixes pure identity protocols with partial ones, and that I dared to include SXIP. Then he misquotes me. I told him to chill. Although I do empathize that he's frustrated... many of us are.
Some of you may have noticed that my "comments" form is looking a bit weird lately... that's because I'm getting WAAAAY too much comments SPAM, and needed to experiment with CAPTCHAs. These are little forms that attempt to distinguish a SPAM robot from a real live human. I'm testing out several varieties to see which ones have been cracked, and which ones are relatively OK.
Naturally, there are many many problems with CAPTCHAs... if the test is too easy, spammers win. If its too hard, people can't solve it, and you don't get any comments. Not to mention its tricky to make one that works for blind and color blind users. And even the best CAPTCHA can be beaten by a "porn proxy": an evil site would offer something good for free (like porn) if a random user solves 5 CAPTCHAs... then the evil site re-uses those solved CAPTCHAs to put spam on somebody's web site.
Others say CAPTCHAs are pointless, and the only real way to prevent comment spam is to make people pay to comment. This could be a micropayment of 2 pennies... or it could be a difficult problem to solve that costs the commenter 2 cents worth of electricity because the CPU is crunching numbers.
I like the latter concept... For example, the SETI @ HOME folks could put together a mini applet that does 1 second worth of CPU work... and then the user configures how many seconds he requires of a commenter before they can post. Most folks wouldn't care less... but spammers might. You could solve very complex, and very useful scientific problems while fighting spam! Not bad... but of course then you'll need Java applets or JavaScript enabled... plus its usefulness is debatable against a zombie network.
I love saying stuff like that...
This is along the same lines of the reCAPTCHA project... which uses the standard image recognition CAPTCHA, except these are images taked from actual books that computers can't read. In theory, you help digitize old books while you fight spam... but my log files says reCAPTCHA has either been hacked, Drupal's implementation is flawed, or reCAPTCHA is popular amongst "porn proxies." Too bad... it was a good idea.
Some sites, like Lifehacker, force you to earn a trusted user account before you can comment. I'm hoping such a solution isn't needed... and I can come up with something that is cross cultural, and fair to the visually impaired.
I'll keep y'all informed of what I eventually discover.
We knew it would happen some day... as soon as the Web 2.0 hype encouraged people to create REST and AJAX APIs, hackers would find fun new ways to abuse them... Today's security scare is brought to you by DNS Rebinding (Hat tip Artur Bergman).
The nifty things about AJAX is that it allows you to make XML requests back to the originating server. It won't let you make requests to other servers, only to the one you are connected to. So if you're browsing the google.com web site, you can only make AJAX requests to google.com. I always thought this same-origin policy was a bit restrictive, and probably wasn't as safe as everybody thought, so it always annoyed me. I usually choose remote scripting instead of AJAX for this reason.
Now it turns out you can completely hijack this same-origin policy with sneaky DNS settings... and an evil web site can use AJAX to connect to any resource behind your corporate firewall!
Lets assume you accidentally go to some evil web site, like evil.com. First, your computer translates evil.com into an IP address, such as 1.2.3.4. Normally, this IP address data is cached for a long time, but its possible to set up evil.com's DNS servers to expire the cache every 5 seconds. That means for every request, your browser needs to look up the IP address again.
So, lets say the hacker (or some robot) at evil.com notices you're on the site. It then changes the DNS address to something different... say 10.10.1.1, or any other IP address inside your corporate network. That means the next request you make to evil.com will be sent to an internal server instead.
It gets worse... If evil.com is running some AJAX, or a Rich Internet Application (Flash/Flex/Apollo/Silverlight), the hacker can use your browser as a proxy through your firewall, and run attacks. Since the IP address is changed to an internal address, any AJAX request made in JavaScript will be able to access an internal server, instead of evil.com. This can be used to send SPAM, change passwords, or read any XML formated content. As long as you keep that browser window open, the hacker has full access to your internal network through your browser!
Pretty evil, those guys at evil.com...
These attack forms are nothing new -- I covered a mundane variation of this in my security presentation at Crescendo 2006... but AJAX plus DNS rebinding makes this method even more attractive to hackers.
If you're running Stellent/Oracle, I'd HIGHLY recommend installing the HtmlPostAuthenticator component. If properly configured, it should really help mitigate attacks of this nature. This attack is also highly noisy, so unless the hacker knows your network very well, most intrusion detection systems should catch it eventually.
In case you use XPath as a query language to your repository (instead of SQL or something else), hopefully you are aware of a little problem called XPath Injection Attacks.
Anybody who knows web apps and security knows of the dangers of SQL injection attacks... many web apps are vulnerable to this. If you have a web form, and generate a SQL query with the data on that form -- without validating the data -- then you're open to attacks. People can inject whatever SQL they want into the web form, and trick your application into running their SQL instead of your SQL. This could cause data leaks, or even data deletion.
You can fix this problem simply by escaping all quotes in the data from the web form... as well as type checking dates and numbers. You may also need to count the parenthesis and remove SQL comments, depending on your application...
XPath injection works in an analogous way to SQL injection... the only different is that the injected attack has a different syntax. If your repository allows XPath query syntax, you'll need to do a lot more data validation to protect yourself...
Now, XPath is typically used to query single XML files. Very few people used it as a full query language to a database or content repository. In my humble opinion, that's for a damn good reason: XPath syntax is awkward and weird. Its totally a step backwards in both usability and performance... however, because of trendy new XML standards, XPath injection may be a bigger problem then you realize. You might be using XPath all over, or your repositories might allow XPath query syntax even if you don't use them.
Case in point, I'd highly recommend that anybody who uses that rotten JSR 170 protocol for content management PLEASE look long and hard at how secure your system actually is... You know who you are... I'd start by reading the XPath Injection Attacks article from IBM.
Bruce Schneier has a rather depressing article in Wired this month, about why bad security products drive good ones out of the market.
In essence, in a market where the seller knows a lot more about the buyer, and there are many options, the buyer bases their purchase decisions on the average product price. The high-end stuff -- which is the only secure option -- is just too expensive to justify. Pretty soon, nobody buys the good stuff, and we're all left with the lemons.
In a used car market, you can use economic signals to correct this market behavior, and drive people to make wise purchases... for example, an independent mechanics can spot a lemon rather quickly. Employ one to help you out, and you can purchase a good cars amongst the lemons.
Unfortunately, those independent experts are incredibly expensive in the software security field... and even they don't instantly know which products are the lemons. It takes weeks or months of intense analysis. Who has the money or time for that?
Other signals, like as encryption standards and company reputation, are useful... but they also are no guarantee. So crappy security products will always get to the market faster and sell better than effective security products.
So very depressed...
So I recently subscribed to the Consumer Reports Money Advisor magazine. Overall, its a very good read. Financial advice from them is usually much more reliable than pundits on the TV or (some) magazines.
This month they had an article about credit monitoring and fraud protection services. Overall, they are crap.
They're pretty expensive, and mostly ineffective. The odds that they'll catch the bad guy is low, and on the off chance they do, sometimes the insurance won't cover a pre-existing condition. Meaning if your identity was stolen 3 years ago in a database hack, but they just opened a credit card with your data last week, your insurance might not cover you.
The two pieces of advice that I thought were the most useful were these:
That second one was a surprise to me... but there are laws on the books in half of the states that allow you to "lock" your credit report for a small (~$10) fee. The advantage here is simple: if they can't give out your credit report, then nobody can take out a credit card or loan in your name!
I thought that was a great idea: its incredibly easy to get somebody's social security number, and open up an account with a stolen name. However, if your credit report is locked, then the credit card company will quickly reject any application.
Since no new accounts are possible, all you need to do is monitor your existing accounts. This is relatively easy, if you do the right thing and use very few credit cards. Also, the laws are on the consumer's side when it comes to credit card transactions. The laws are a little less nice when it comes to wiring money between banks, so opening up an bank account with some level of fraud protection might still be a good idea.
Just be sure to read the fine print...
An interesting case is working its way through the courts at the moment...
At exactly 5:45:34 on April 18, 2004 a computer taken from the office of the attorney of Melanie McGuire, did a search on the words "How To Commit Murder."
Ms. McGuire apparently searched both Google and MSN for undetectable poisons, instant poisons, and fatal digoxin doses.
Ten days later, her husband was murdered -- allegedly by Ms. McGuire -- and with a gun.
Apparently her Google skills weren't so hot...
In any event, it raises the question, what if during a criminal investigation that has nothing to do with you, suddenly a judge demands to see your company's web access logs?
Do you have the tools to search old logs for who did what, and when? How long do you even retain those logs? Do you have an official written policy about destroying those logs?
Are your old logs even "discoverable"? Meaning, is it legal for a judge to demand to see them? If they are only on backup tapes, then you might be able to fight it... otherwise the judge could force you to produce them.
And what if you don't have the right software tools for this? You may have to hand over all your company's logs to the judge, and let a third party specialist analyze them. And hopefully that specialist doesn't happen to work for your competition.
These are all interesting questions... and more like them will crop up as Records Managers get more interested in web sites...
In the case of Ms. McGuire, it was sufficient to look through her browser history to see what she Googled. However, she could have been a bit of a hacker, and deleted those local logs. The next easiest place to get that information is to ask Google. Get the IP address for her computer from her ISP, then ask Google for all items searched for by somebody with that IP address.
But would Google want to do that? What about the cost? The hassle? And the violation of Google's don't be evil policy?
Google has recently instituted an anonymous log policy. Ostensibly this is so they can protect your privacy, and conform with some European laws.
I think that its also bit selfish: they just don't want it to become standard operating procedure for cops to demand Google logs for all suspects. That would affect Google's profits.
You might want to come up with a similar policy... yes, you need access logs so you can track what's hot and what's not... but if you don't have an official policy of anonymizing that data after its useful, you might someday be served with a warrant.
I'm not making this up...
The SITE Institute has acquired and translated the first issue of the Technical Mujahid, a magazine dedicated to helping Islamic jihadists secure their computers.
Some of their analysis included:
Articles like, "The Technique of Concealing Files from View" and "How to Protect Your Files, Even if Your Device was Penetrated," were written for the intermediate to advanced user, and describe a variety of methods and software that provide security. Links to download referenced software, such as the VMware virtual machine, and key generators to unlock features are also given by the editors. Another writer discusses PGP (Pretty Good Privacy) software and determines that its encryption is not adequate for the needs of the Mujahideen.
So... the jihadists have determined that encryption is not sufficient to secure their data. I wonder how long it will take Wall Street to figure that out! ;)
Seriously, when stuff like this hits the internet, it makes me wonder how much longer wars -- even little wars -- can be used to accomplish a lasting goal.
It makes me think that the writers of The Fifth Dicsipline are right... the only way for any group to survive is if it learns faster than opposing groups.
I'm reading into it a bit... but basically any culture that can embrace the wild and free marketplace of ideas on the internet will thrive... even if the immediate result is unrest, power shifts, or the threat of "foreign ideas" befouling the "purity" of the existing group. This applies equally well to countries, cultures, corporations, and religions.
Any group so dogmatic that they refuse to learn from anything unless it was written 2000 years ago, will likely find themselves left behind.
OK, you mean Amazon turkeys, I'm on to you!
I suddently noticed a lot of access denied messages in my error logs. Some one or some thing has been trying to edit my blog posts... luckily I keep my security patches up to date.
Anyway, I recorded the IP addresses, and used ARIS WHOIS to trace back their IP addresses, and guess what? Its Amazon.com.
Hookay...
I don't know if its a sysadmin who was mad that I posted info on security holes at Amazon.com (which they fixed nicely)... a hacker who is disguising their IP address... or a misconfigured web spider. It could be a taunt, an accident, or malice.
In any event, I'll be contacting them and my ISP in the morning. I hope I can schmooze a free book out of this...
Recent comments
9 hours 42 min ago
2 days 14 hours ago
2 days 18 hours ago
3 days 1 hour ago
3 days 14 hours ago
3 days 15 hours ago
3 days 15 hours ago
3 days 15 hours ago
3 days 21 hours ago
4 days 4 min ago