0762423374.01._PF_PE10_PU5_PE09_PU5_PE08_PU5_PE07_PU5_PE06_PU5_PE05_PU5_PE04_PU5_PE03_PU5_PE02_PU5_PE01_.jpg

May 26, 2005 6:49 AM

Abusing Amazon images. And you thought URL manipulation was a lost art.
posted by DrJohnEvans (27 comments total)

via kottke but worth it.
posted by DrJohnEvans at 6:49 AM on May 26, 2005

Is it unbearably childish that I laughed out loud at "Dirty Underwear"?

Is it merely bearably childish?
posted by oddman at 6:54 AM on May 26, 2005

thats awesome. i love a good web hack.
posted by Mach5 at 7:04 AM on May 26, 2005

It's also just evidence of someone doing something right, under the hood. Sure, now they've got a little bit of a PR flap, and maybe a little security gap to fix (if they want to bother), but someone on the coding team there clearly thought through a flexible and robust approach to displaying product images.
posted by LairBob at 8:00 AM on May 26, 2005

That's very cool. Also very helpful for Wikipedia which uses book cover images under fair use. ~~~~
posted by stbalbach at 8:04 AM on May 26, 2005

Pretty cool. People have a lot more time on their hands than I think they really know what to do with.
posted by OmieWise at 8:21 AM on May 26, 2005

I'm surprised that Amazon has this vulnerability. Lots of companies use some kind of dynamic image generation like this -- it is good practice -- but they don't usually let you get at it through the URL. Normally the calls that generate the image are only allowed in middle-tier code.

Fun hack.
posted by gurple at 8:25 AM on May 26, 2005

Why would this be a security flaw? Surely the item pricing in their shopping cart solution is not determined based on the image file name in the page? Moreover, you can not get an amazon page with whatever picture you want, you'd have to make a local copy, or possibly use phishing techniques to make the page appear as if it was displayed on amazon. I doubt a screenshot of an item at 99% off would convince amazon.

I just really see no security implications in this. It's a neat hack, you can make funny pictures with it, but that's about it, no?
posted by splice at 8:28 AM on May 26, 2005

It's a very minor security flaw. They use up some processor time and disk and memory space creating and caching these images (so as not to have to recreate them every time). You could make them do some extra work, that's pretty much it. Maybe a million hits at once for custom images would overload some server or other; probably not, probably they have safeguards against that.
posted by gurple at 8:29 AM on May 26, 2005

Yeah, this definitely doesn't seem like something they'd have to worry about. All anyone can do is manipulate some images, and they almost certainly don't want to make it too hard to access, since I'm sure it's very useful for all their z-shops, resellers, affiliates, etc.
posted by LairBob at 8:43 AM on May 26, 2005

They've intentionally loosened control on direct-image linking, because they are making so much $$$ through affiliates hawking their wares (and direct linking their images) on other websites. Before kottke, this was on hack-a-day (where the hacks usually require tools and basic electronics knowledge but are fun to see for those of us with neither).
posted by Zurishaddai at 9:14 AM on May 26, 2005

Fun link. Thank you, Dr.John.
posted by soyjoy at 9:31 AM on May 26, 2005

I used to work at Amazon; we had a tool to generate the proper URLs for these images. Looks like the system has seen an upgrade sometime in the last year or so -- it used to only allow you to apply a single badge in a single location, specify the size, and optionally add the shadow and CD image. You could also generate a 'fan' of three products using the system, but that was about it -- you couldn't keep adding on features like you apparently can now, and you couldn't arbitrarily rotate images.

That being said, he missed one of the badge possibities. PE1C will generate a "One Cent" badge. My internal Amazon site forced that badge to be on all of the product images, making it look like I was selling all of the products for a penny.

Good times, good times.
posted by limbostar at 9:33 AM on May 26, 2005

Nice! I wonder what would happen if someone manipulated a URL, sent that to someone else and they tried to buy it with the 55% off tag? Does the URL drive the checkout as well?

Must go do more investigation.
posted by fenriq at 9:44 AM on May 26, 2005

...And do they have cameras?
posted by soyjoy at 10:34 AM on May 26, 2005

Limbostar: once a variation has been created, is it stored somewhere so it doesn't have to be generated a second time? Or are they all generated on the fly at all times?
posted by o2b at 11:09 AM on May 26, 2005

On another note, I once saw, at a conference, a demonstration of what could be the software running this. It was from IBM, I think, it cost somewhere in the range of $150-200 thousand dollars, and was literally the Adobe Photoshop engine partnered with some non-visual front-end application that you could hook into some other CMS-type application. (Forgive my non-technical understanding of it. I'm a front-end guy.) Anything you could do in Photoshop (and save as an action) you could do in this application.
posted by o2b at 11:14 AM on May 26, 2005

Geeky and witty. I like it.
posted by jacquilynne at 11:17 AM on May 26, 2005

fenriq writes "Does the URL drive the checkout [price] as well?"

I really can't imagine that it does--to give URL control over the actual checkout price would be an enormous mistake. I'd be surprised if there weren't a connection the other way around, where the discount in the price DB generates the appropriate image URL for this, but the way you've described it would just be unthinkable.
posted by LairBob at 11:26 AM on May 26, 2005

LairBob, I thought so but had to ask because it would be fun to monkey with then.
posted by fenriq at 11:29 AM on May 26, 2005

The images are cached, yes. They have (had?) an image server / series of servers which keeps track of what images are being requested the most, and keeps them in RAM. Less often requested images are kept in a disk cache; very rarely requested images are generated on the fly. The disk caches are pretty huge, you only have to request an image once or twice to get it shoved there.

As for this possibly messing up the price of the order, there's about a bazillion places where the price being recorded is confirmed with the price in the database. There have been times when someone found a way to mess up the process, but not with something like this. This is just a convienent way to generate images, so they don't have to pay graphic designers to put little badges on product images six thousand times a day.
posted by limbostar at 11:59 AM on May 26, 2005

On another note, I once saw, at a conference, a demonstration of what could be the software running this. It was from IBM, I think, it cost somewhere in the range of $150-200 thousand dollars, and was literally the Adobe Photoshop engine partnered with some non-visual front-end application that you could hook into some other CMS-type application.

Gimp can do this, in the $0-$0 thousand dollar range. I kinda doubt amazon is using either system, as their system seems rather limited and could be done with a number of OSS products.
posted by delmoi at 1:50 PM on May 26, 2005

This is cute, if a complete waste of time. I can't believe there's a gallery. Yay URL hackery.
posted by blacklite at 2:08 PM on May 26, 2005

Funny I noticed this while making up this ask.me post, didn't know it was this flexible, though. Cool.
posted by Space Coyote at 6:52 PM on May 26, 2005

Gimp's engine is unsuitable for embedding, and the filters aren't very fast anyways. There aren't many open source candidates for building high-performance image rendering software, all of the options out there have pretty serious downsides.

And limbostar, the time it takes to send an image back to a customer is several orders of magnitude more than the time it takes to read the image from disk. Placing commonly-accessed images in memory is kind of missing the point.

I remember interviewing candidates and asking them how to speed up a slow image server system, and almost all of them choose to place the images in memory. That's just about the worst cost/performance decision you can make. For some types of data, you don't want to explicitly place your payloads in memory, you just want to load files from disk and send them out, letting the buffer cache decide what's hot and what's not. Images are one of those types of data.
posted by beaverd at 6:53 PM on May 26, 2005

beaverd, I didn't design the system, I just used it. They cached images in memory, and the perf team (who I assume has an interest in this sort of thing) reviewed it extensively. I don't know *how* they chose to cache them in RAM -- for all I know they just let the kernel take care of it.

Of course, for all I know they used a team of elves to enter individual bits into RAM. Like I said, I just used it.
posted by limbostar at 7:51 AM on May 27, 2005

http://www.php.net/gd
posted by tyamada at 10:50 AM on May 27, 2005