Slashdot Mirror
TinyDisk, A File System on Someone Else's Web App
Psy writes "I attended Phreaknic this weekend where Acidus released TinyDisk, a shared file system that runs on top of TinyURL or his own implementation NanoURL. TinyDisk compresses a file, encrypts it, and dices it into clusters. Each cluster is submitted to TinyURL as if it were a url. This clusters can be read back out of the database, making TinyDisk a global file system anyone can use. There are safeguards in the default config to prevent people from dumping gigs of MP3s into TinyURL. While file-system-on-web-applications are nothing new (GMail file system anyone?) this hack shows how easy it is to accidentally design a web application insecurely despite the default PHP protections. See his presentation for more info"
I saw this a few hours ago, and from what I understand the process goes as follows:
:)
1- Open a meta file
2- Retrieve and concatenate all the clusters from TinyURL in the order
specified in the meta file.
2- Base64 decode the file
3- Decrypt the file with the algorithm and key in the meta file
4- Decompress the file with the algorithm in the meta file.
5 - Verify the file size given in the meta file is correct for the
decoded/decrypted/decompressed file
6- Verify the checksum with the algorithm and value in the meta file matches
for the decoded/decrypted/decompressed file
7- Set the filename of the decoded/decrypted/decompressed file to the
filename specified in the meta file.
Hope that helps somebody
46487 466780 252994 376409 96920 39622 205366 244315 622115 512361 668040 63608 259203 955314 811176 652718 166330 23922
Sure, well all know PHP is far from synonymous with security, but this seems to be a case of exploiting a web app using only the mechanics intentionally made available, just in a novel way. Seems like some unfounded (though not necessarily undeserved) PHP bashing.
URLs could be checked on the serverside on availability for example; if your URL is phony, then it's rejected. I suppose that would make massive DOS-attacks possible, but hey - we could also do a count on the frequency that URLs are submitted from one source, _and_ we could count the amount of times a certain host is referenced.
I've used something similar myself, and there are a few obscure reasons for hiding data in somebody else's web application.
For instance, Opera's UserJS (the inspiration for Greasemonkey) doesn't have a restriction-free XMLHttpRequest object, so the only information you can retrieve with it is from the original host. Stuffing data onto that host is sometimes the only way of making some features work.
Bogtha Bogtha Bogtha
That is a great idea . It would also double as a feature , incase anyone accidentally mistypes a URL or misses a chunk at the end during a copy/paste
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Here is a video of Acidus's presentation. If you haven't seen him present before (At Hope, O'Reilly's E-Tech, Toorcon, Phreaknic, Interz0ne, etc, etc) he puts on a good show.
The presentation was called: Layer 7 Fun: Extending web applications in interesting ways. He discusses how traditional web applications work -vs- "new" web ppas that use AJAX. He talks about writing extensions to web apps using an API supplied (ala Housingmaps.com, or chicagocrime.org). Finally he talks about writing an extension to a web app where you don't have access to an API. TinyDisk was a case study for writes these so-called "non-sanctioned" extensions. He has a funny little slide he goes back to about how to properly implement a web app (which TinyRUL fails to do). Things like "don't wallow users to uploaded arbitrary amounts of data directly into your database."
Funny Stuff. His upcoming talk at Shmoocon seems pretty cool too.
In the Recommended reading section this is stated:
There are definitive works in certain fields that online guides and HOWTOs cannot even approach in terms of detail or quality. It's a class of books that are so familiar people refer to them by nicknames instead of by full title.
Well maybe so, but I did not know them all, and in the interest of helping people along the path here they are:
Books like:
K&R, The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie
The Dinosaur Book, Operating System Concepts by Abraham Silberschatz
Knuth's never-ending story, The Art of Computer Programming, but Donald Knuth
The White Book, Introduction To Algorithms by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Cliff Stein
P&H, Computer Organization and Design The Hardware/Software Interface David Patterson John Hennessy
The Illustrated's. TCP/IP Illustrated Series (The Illustrated's) - W. Richard Stevens
The Rainbow series. U.S. DOD Computer Security Series
Have you Meta Moderated t
"PHP as little to none default protection so much so that they make it insecure by default. You would have to go through a considerable amount of work to make any script secure."
Really? So in what way is 'echo "hello world";' insecure? The only PHP scripts that are insecure are the ones where programmers made stupid decisions or wasn't thinking the design through, just like in any other language. 99% of these PHP problems are using external data without checking it. 99% of those cases are where the programmer didn't use the readily available tools such as prepared SQL statements.
In fact, with PHP in its default configuration, a script that does not accept user data has zero chance for exploitation. You do get cases where programmers do exceedingly stupid things such as get data in such a way as so internal data can be injected, but programming that way is actually much more difficult than doing it the right way. Programs ported from very old versions of PHP may suffer from this if they weren't ported properly.
Anyway, this is all aside from the fact that the TinyURL issue isn't a vulnerability caused by PHP. The program is working exactly as intended, but the programmers didn't think about it being used in this way. They could have easily written a couple lines of code to check to make sure the URL is valid before accepting it.
The global economy is a great thing until you feel it locally.
Let us not forget, we are NOT COMPRESSING ANYTHING.
/usr/home/SamSim/foo.txt) is compressing the contents of foo.txt to the length of the path.
We are simply addressing it. By your definition, a filesystem path (e.g.
I pity the foo that isn't metasyntactic
Why isn't it a filesystem? Filesystems have been around since long before Posix.
/proc filesystem - accessing in-memory data
A filesystem stores and retrieves files.
Here are some exmaples of filesystems that undoubtably violate posix:
FAT as shipped in DOS 1.0
Had no subdirectories
Had no notion of users
Had no permissions
Limited filenames to 8.3
CD-R
Doesn't allow data to be modified (or meta-data to be changed).
In addition, some filesystems allow remote access:
NFS
andrewfs
Coda
In addition, some OS'es allow some things to be treated as filesystems:
Linux has
Hurd allows filesystem access to tar files, and ftp servers
So, why isn't it a filesystem?
Where law ends, tyranny begins -- William Pitt
Visual captchas present a significant usability problem for blind users, and audio captchas have proven much easier to defeat in general than visual captchas (some of which are actually quite easily defeated).
Further, even the best visual captchas are easily overridden if the attacker is motivated enough; a common means to perform this action is to get other humans to voluntarily solve the captchas as they are encountered by offering, eg, free porn.
Basically, captchas aren't really the solution to preventing bots (there are no good solutions for this), they only deter casual botters.
Slay a dragon... over lunch!