Re: State of Digibug module

[Bharat Mediratta]

Tim Almdal wrote:
> Here's what's left:
>
>    1. "we only need to use the proxy for photos where you don't have
>       view_full privs"
 >
>       I think its risky to do that.  I'd prefer to leave the proxy for
>       everything.  One its less code (don't have to check about
>       permissions). Ok, its only a couple of lines.  Secondly, there is
>       a time delay between order placement and order fulfillment
>       permissions could have been removed.

Yes, but then you're also overloading the proxy table which might
require you to have a task to do cleanup, etc.  If you use the public
url, there are less moving parts for most operations because the remote
server is just dealing with publicly available files.  Removing
permissions during the time delay is an extreme edge case here.  The
time delay is going to approach zero in most cases.

>    2. "there's no security in print_photo() -- I can use it to get access
>       to full size photos even if I can't view them"
 >
>       I guess, if you know the url you can, I'm open to suggestions
>       regarding closing that hole.  In some cases that is point of this.
>       On my gallery I will probably remove view fullsize from every one
>       but allow them to print it which requires access to the fullsize
>       behind the scenes.

Digibug_Controller::print_photo() takes an item id and creates a proxy
url for it, then returns the proxy form.  This means that I can go to
your website, guess and id (say, 35) and create a url like:

    http://example.com/gallery3/print_photo/35

This will give me a url that lets me view the full size.  No permission
checks have been run.  This is a security hole.  print_photo needs to
verify that the caller can view the full size before it creates a proxy
for it.

Are you confusing print_photo() and print_proxy() here?  print_proxy()
requires the $uuid (might help if you renamed the variables in the
method definition to make that more clear).


>    3. "I'd simplify all of this and ditch the advanced mode altogether.
>       It's way too much choice and text for G3.  Plus all the marketing
>       stuff on the settings page.. that all looks like G2."
 >
>       I've cut out most of the cruft so its a lot lighter and not so g2
>       like.  I'd prefer being able to enter my own company and event id,
>       so I'd rather not have to go to advanced settings.  In fact, if we
>       weren't time constrained I would have implemented the patch I had
>       created for g2 to allow event ids to be assigned to groups and users.

You're an edge case.  Don't optimize for yourself here.  Right now if I
go to that page I'm mightily confused.  I'm presented with a signup page
and a couple of empty text boxes.  I don't care about any of that
stuff-- I just want to allow people to make prints.  Start with the
simplest possible thing-- hardcode the values and don't make them
editable.  The point in making Admin > Settings > Advanced is so that we
*don't* have to create a confusing UI just to support our power users.
More work needed here.

>    4. "ditch basic_company_id and basic_event_id and just have the
>       company_id and event_id prefilled.  Don't even allow users to
>       change them for now (advanced users can always change those values
>       in Admin > Settings > Advanced later on.  Perhaps add some simple
>       text and a link to the Digibug site and their logo"
 >
>       I like having the basic settings, so an admin can switch back and
>       forth.  I guess what I could do (and maybe this what your saying)
>       is bag the tabs, just have the content that's on the advanced and
>       add a "default" button to reset to gallery's company and event ids

More of what I said above.  This is still too confusing.  Let's start by
supporting our 80% case.  Those users want to activate the module, do
zero configuration, and have print buttons appear.  Realistically, we
could just ditch the Digibug settings page altogether for 3.0 and put up
a FAQ telling people how to sign up and change their ids and.

>    6. Just thought of this... how do you want to handle non jpeg
>       images.  The Digibug api will only handle jpegs.  Not show the
>       button if its not a jpeg? (simple and quick) or do a conversion
>       (more complete, but a pita to manage the converted image).  I'm
>       leaning to the first option.

I like #1.

>    7. Will try to put the digibug window into an iframe in a dialog and
>       see how that works (Chad's suggestion)

I just tried printing and got this error:

There was an SQL error: Table 'g3dev.g3_digibug_proxies' doesn't exist -
SHOW COLUMNS FROM `g3_digibug_proxies`

I haven't looked at the code, but I'm guessing this means that you
modified the database but didn't add upgrade support?  I guess we don't
have a policy for what we do in that case, but now that we're post-beta
we should do our best to support upgrades for any changes that we make.

I think this means that we don't commit stuff back to the main repo
until it's passed some level of review, and once its in the main repo we
support the proper upgrade path.

I doubt many people have been bitten by this so far, so I think the
easiest thing to do is to seek forgiveness in this case, but in the
future we should probably keep modules out of the main repo until you
and I agree on the structure first to avoid writinga lot of upgrade code.

-Bharat

PS: for anybody playing along at home, you might want to drop the
"proxies" table from your g3dev if you installed the digibug module
yesterday.


------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Tim Almdal]

1. Regarding changing the table name and no update path.  My thinking was that we had guaranteed an upgrade path between beta 1 and beta 2, we had said nothing about the in between steps.  I'll be more careful in the future.
2. I'm now confused: in your pt 2, you talk about needing view full permission in order to access the full image to print, otherwise there is this security whole.  Then we talk about using the print_proxy if you don't have access to view the full size image.  To me these two requirements seem mutually exclusive (i.e. there is no need for a print proxy).
   My view of how this should work, is that the admin (me) wants to remove view full size permissions from everybody, but I want to allow a visitor to print an image if they like it.  so I want them to press the print button and they enter their order in digibug. So in my scenario they don't have access to the full size image, but Digibug via the print proxy has access.  How do we address your security concern but leave this scenario in place.
3. As for the admin page, I figure, its there, we have other priorities lets declare a victory and move on.
4. And I had a task to clean up expired entries, but I refactored  that to be done when an image is requested via the proxy.  Again, I think that not using the proxy adds a complication and adds nothing to the functionality.  Again, lets declare a victory and move on.
   

Bharat Mediratta wrote:

Tim Almdal wrote:

Here's what's left:

   1. "we only need to use the proxy for photos where you don't have
      view_full privs"

>

      I think its risky to do that.  I'd prefer to leave the proxy for
      everything.  One its less code (don't have to check about
      permissions). Ok, its only a couple of lines.  Secondly, there is
      a time delay between order placement and order fulfillment
      permissions could have been removed.

Yes, but then you're also overloading the proxy table which might require you to have a task to do cleanup, etc.  If you use the public url, there are less moving parts for most operations because the remote server is just dealing with publicly available files.  Removing permissions during the time delay is an extreme edge case here.  The time delay is going to approach zero in most cases.

   2. "there's no security in print_photo() -- I can use it to get access
      to full size photos even if I can't view them"

>

      I guess, if you know the url you can, I'm open to suggestions
      regarding closing that hole.  In some cases that is point of this.
      On my gallery I will probably remove view fullsize from every one
      but allow them to print it which requires access to the fullsize
      behind the scenes.

Digibug_Controller::print_photo() takes an item id and creates a proxy url for it, then returns the proxy form.  This means that I can go to your website, guess and id (say, 35) and create a url like:

   http://example.com/gallery3/print_photo/35

This will give me a url that lets me view the full size.  No permission checks have been run.  This is a security hole.  print_photo needs to verify that the caller can view the full size before it creates a proxy for it.

Are you confusing print_photo() and print_proxy() here?  print_proxy() requires the $uuid (might help if you renamed the variables in the method definition to make that more clear).

   3. "I'd simplify all of this and ditch the advanced mode altogether.       It's way too much choice and text for G3.  Plus all the marketing
      stuff on the settings page.. that all looks like G2."

>

      I've cut out most of the cruft so its a lot lighter and not so g2
      like.  I'd prefer being able to enter my own company and event id,
      so I'd rather not have to go to advanced settings.  In fact, if we
      weren't time constrained I would have implemented the patch I had
      created for g2 to allow event ids to be assigned to groups and users.

You're an edge case.  Don't optimize for yourself here.  Right now if I go to that page I'm mightily confused.  I'm presented with a signup page and a couple of empty text boxes.  I don't care about any of that stuff-- I just want to allow people to make prints.  Start with the simplest possible thing-- hardcode the values and don't make them editable.  The point in making Admin > Settings > Advanced is so that we *don't* have to create a confusing UI just to support our power users. More work needed here.

   4. "ditch basic_company_id and basic_event_id and just have the
      company_id and event_id prefilled.  Don't even allow users to
      change them for now (advanced users can always change those values
      in Admin > Settings > Advanced later on.  Perhaps add some simple
      text and a link to the Digibug site and their logo"

>

      I like having the basic settings, so an admin can switch back and
      forth.  I guess what I could do (and maybe this what your saying)
      is bag the tabs, just have the content that's on the advanced and
      add a "default" button to reset to gallery's company and event ids

More of what I said above.  This is still too confusing.  Let's start by supporting our 80% case.  Those users want to activate the module, do zero configuration, and have print buttons appear.  Realistically, we could just ditch the Digibug settings page altogether for 3.0 and put up a FAQ telling people how to sign up and change their ids and.

   6. Just thought of this... how do you want to handle non jpeg
      images.  The Digibug api will only handle jpegs.  Not show the
      button if its not a jpeg? (simple and quick) or do a conversion
      (more complete, but a pita to manage the converted image).  I'm
      leaning to the first option.

I like #1.

   7. Will try to put the digibug window into an iframe in a dialog and
      see how that works (Chad's suggestion)

I just tried printing and got this error:

There was an SQL error: Table 'g3dev.g3_digibug_proxies' doesn't exist - SHOW COLUMNS FROM `g3_digibug_proxies`

I haven't looked at the code, but I'm guessing this means that you modified the database but didn't add upgrade support?  I guess we don't have a policy for what we do in that case, but now that we're post-beta we should do our best to support upgrades for any changes that we make.

I think this means that we don't commit stuff back to the main repo until it's passed some level of review, and once its in the main repo we support the proper upgrade path.

I doubt many people have been bitten by this so far, so I think the easiest thing to do is to seek forgiveness in this case, but in the future we should probably keep modules out of the main repo until you and I agree on the structure first to avoid writinga lot of upgrade code.

-Bharat

PS: for anybody playing along at home, you might want to drop the "proxies" table from your g3dev if you installed the digibug module yesterday.

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.339 / Virus Database: 270.12.91/2201 - Release Date: 06/25/09 06:22:00

  

------------------------------------------------------------------------------

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Tim Almdal]

Further to: Don't know about you, but, if i try http://example.com/gallery3/print_photo/35 I get a forbidden exception and if I go put the csrf value on, I end up redirecting to the digibug shopping cart, but no link to the full size is exposed.  Maybe, I'm a little dense tonight, but I'm not sure where the security concern is.

Tim Almdal wrote:

1. Regarding changing the table name and no update path.  My thinking was that we had guaranteed an upgrade path between beta 1 and beta 2, we had said nothing about the in between steps.  I'll be more careful in the future.
2. I'm now confused: in your pt 2, you talk about needing view full permission in order to access the full image to print, otherwise there is this security whole.  Then we talk about using the print_proxy if you don't have access to view the full size image.  To me these two requirements seem mutually exclusive (i.e. there is no need for a print proxy).
   My view of how this should work, is that the admin (me) wants to remove view full size permissions from everybody, but I want to allow a visitor to print an image if they like it.  so I want them to press the print button and they enter their order in digibug. So in my scenario they don't have access to the full size image, but Digibug via the print proxy has access.  How do we address your security concern but leave this scenario in place.
3. As for the admin page, I figure, its there, we have other priorities lets declare a victory and move on.
4. And I had a task to clean up expired entries, but I refactored  that to be done when an image is requested via the proxy.  Again, I think that not using the proxy adds a complication and adds nothing to the functionality.  Again, lets declare a victory and move on.
   

Bharat Mediratta wrote:

Tim Almdal wrote:

Here's what's left:

   1. "we only need to use the proxy for photos where you don't have
      view_full privs"

>

      I think its risky to do that.  I'd prefer to leave the proxy for
      everything.  One its less code (don't have to check about
      permissions). Ok, its only a couple of lines.  Secondly, there is
      a time delay between order placement and order fulfillment
      permissions could have been removed.

Yes, but then you're also overloading the proxy table which might require you to have a task to do cleanup, etc.  If you use the public url, there are less moving parts for most operations because the remote server is just dealing with publicly available files.  Removing permissions during the time delay is an extreme edge case here.  The time delay is going to approach zero in most cases.

   2. "there's no security in print_photo() -- I can use it to get access
      to full size photos even if I can't view them"

>

      I guess, if you know the url you can, I'm open to suggestions
      regarding closing that hole.  In some cases that is point of this.
      On my gallery I will probably remove view fullsize from every one
      but allow them to print it which requires access to the fullsize
      behind the scenes.

Digibug_Controller::print_photo() takes an item id and creates a proxy url for it, then returns the proxy form.  This means that I can go to your website, guess and id (say, 35) and create a url like:

   http://example.com/gallery3/print_photo/35

This will give me a url that lets me view the full size.  No permission checks have been run.  This is a security hole.  print_photo needs to verify that the caller can view the full size before it creates a proxy for it.

Are you confusing print_photo() and print_proxy() here?  print_proxy() requires the $uuid (might help if you renamed the variables in the method definition to make that more clear).

   3. "I'd simplify all of this and ditch the advanced mode altogether.       It's way too much choice and text for G3.  Plus all the marketing
      stuff on the settings page.. that all looks like G2."

>

      I've cut out most of the cruft so its a lot lighter and not so g2
      like.  I'd prefer being able to enter my own company and event id,
      so I'd rather not have to go to advanced settings.  In fact, if we
      weren't time constrained I would have implemented the patch I had
      created for g2 to allow event ids to be assigned to groups and users.

You're an edge case.  Don't optimize for yourself here.  Right now if I go to that page I'm mightily confused.  I'm presented with a signup page and a couple of empty text boxes.  I don't care about any of that stuff-- I just want to allow people to make prints.  Start with the simplest possible thing-- hardcode the values and don't make them editable.  The point in making Admin > Settings > Advanced is so that we *don't* have to create a confusing UI just to support our power users. More work needed here.

   4. "ditch basic_company_id and basic_event_id and just have the
      company_id and event_id prefilled.  Don't even allow users to
      change them for now (advanced users can always change those values
      in Admin > Settings > Advanced later on.  Perhaps add some simple
      text and a link to the Digibug site and their logo"

>

      I like having the basic settings, so an admin can switch back and
      forth.  I guess what I could do (and maybe this what your saying)
      is bag the tabs, just have the content that's on the advanced and
      add a "default" button to reset to gallery's company and event ids

More of what I said above.  This is still too confusing.  Let's start by supporting our 80% case.  Those users want to activate the module, do zero configuration, and have print buttons appear.  Realistically, we could just ditch the Digibug settings page altogether for 3.0 and put up a FAQ telling people how to sign up and change their ids and.

   6. Just thought of this... how do you want to handle non jpeg
      images.  The Digibug api will only handle jpegs.  Not show the
      button if its not a jpeg? (simple and quick) or do a conversion
      (more complete, but a pita to manage the converted image).  I'm
      leaning to the first option.

I like #1.

   7. Will try to put the digibug window into an iframe in a dialog and
      see how that works (Chad's suggestion)

I just tried printing and got this error:

There was an SQL error: Table 'g3dev.g3_digibug_proxies' doesn't exist - SHOW COLUMNS FROM `g3_digibug_proxies`

I haven't looked at the code, but I'm guessing this means that you modified the database but didn't add upgrade support?  I guess we don't have a policy for what we do in that case, but now that we're post-beta we should do our best to support upgrades for any changes that we make.

I think this means that we don't commit stuff back to the main repo until it's passed some level of review, and once its in the main repo we support the proper upgrade path.

I doubt many people have been bitten by this so far, so I think the easiest thing to do is to seek forgiveness in this case, but in the future we should probably keep modules out of the main repo until you and I agree on the structure first to avoid writinga lot of upgrade code.

-Bharat

PS: for anybody playing along at home, you might want to drop the "proxies" table from your g3dev if you installed the digibug module yesterday.

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.339 / Virus Database: 270.12.91/2201 - Release Date: 06/25/09 06:22:00

  

------------------------------------------------------------------------------
  

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.375 / Virus Database: 270.12.93/2204 - Release Date: 06/26/09 18:00:00

  

------------------------------------------------------------------------------

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Tim Almdal wrote:
> Further to: Don't know about you, but, if i try
> http://example.com/gallery3/print_photo/35 I get a forbidden exception
> and if I go put the csrf value on, I end up redirecting to the digibug
> shopping cart, but no link to the full size is exposed.  Maybe, I'm a
> little dense tonight, but I'm not sure where the security concern is.

You're sending a <form> back to the browser, then telling it to submit
the form.  But the form has the print_proxy url in it!  So try
intercepting the form.  You can do this by snooping network traffic,
modifying your local dns entry for digibug.com, disabling Javascript,
using Firebug, curl, wget, or lots of other ways.  When I do this, I see:

form action="http://www.digibug.com/dapi/order.php" method="post">
    <input type="hidden" name="digibug_api_version" value="100"  />
...
<input type="hidden" name="image_1"
value="http://example.com/index.php/digibug/print_proxy/73db0f04da7cdf319c68ee11c5526a54"
 />
    </form>

Now I've got the url to a full size image for which I have no
permissions to see.  :-(

I'm doing a pass over the Digibug module now and will fix this up along
with some other stuff (the XSS wasn't fully closed, I'm going to
simplify the UI, etc).

-Bharat

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Closure: I've finished making updates to Digibug and have enforced
security.  Tim and I are now disagreeing about the functionality of the
print module.

Tim's point is that you should be able to print photos without letting
the user see the full size.  My point is that we should not have a
module that subverts our view_full permission.  Current state of the
world is that Tim is going to try to figure out a way to get the
functionality we want without sacrificing security.

-Bharat

Bharat Mediratta wrote:

> Tim Almdal wrote:
>> Further to: Don't know about you, but, if i try
>> http://example.com/gallery3/print_photo/35 I get a forbidden exception
>> and if I go put the csrf value on, I end up redirecting to the digibug
>> shopping cart, but no link to the full size is exposed.  Maybe, I'm a
>> little dense tonight, but I'm not sure where the security concern is.
>
> You're sending a <form> back to the browser, then telling it to submit
> the form.  But the form has the print_proxy url in it!  So try
> intercepting the form.  You can do this by snooping network traffic,
> modifying your local dns entry for digibug.com, disabling Javascript,
> using Firebug, curl, wget, or lots of other ways.  When I do this, I see:
>
> form action="http://www.digibug.com/dapi/order.php" method="post">
>     <input type="hidden" name="digibug_api_version" value="100"  />
> ...
> <input type="hidden" name="image_1"
> value="http://example.com/index.php/digibug/print_proxy/73db0f04da7cdf319c68ee11c5526a54"
>  />
>     </form>
>
> Now I've got the url to a full size image for which I have no
> permissions to see.  :-(
>
> I'm doing a pass over the Digibug module now and will fix this up along
> with some other stuff (the XSS wasn't fully closed, I'm going to
> simplify the UI, etc).
>
> -Bharat
>
> ------------------------------------------------------------------------------
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris F-2]

Just an idea for this. Can a random string or something unique to the server for that image be added to this URL.

That way the full image URL can be passed to a certain function, however a users/system cannot "guess" any other URLs of other images.

The only way you can subvert the full permission of an image is by knowing basically the URL plus the 'key' to that individual image.

So the url would be something similar to:

http://example.com/gallery3/print_photo/35/12390239bbf32f

And the random keys would not be sequential or guessable.

Bharat Mediratta wrote:

Closure: I've finished making updates to Digibug and have enforced
security.  Tim and I are now disagreeing about the functionality of the
print module.

Tim's point is that you should be able to print photos without letting
the user see the full size.  My point is that we should not have a
module that subverts our view_full permission.  Current state of the
world is that Tim is going to try to figure out a way to get the
functionality we want without sacrificing security.

-Bharat

Bharat Mediratta wrote:
> Tim Almdal wrote:
>> Further to: Don't know about you, but, if i try
>> http://example.com/gallery3/print_photo/35 I get a forbidden exception
>> and if I go put the csrf value on, I end up redirecting to the digibug
>> shopping cart, but no link to the full size is exposed.  Maybe, I'm a
>> little dense tonight, but I'm not sure where the security concern is.
>
> You're sending a <form> back to the browser, then telling it to submit
> the form.  But the form has the print_proxy url in it!  So try
> intercepting the form.  You can do this by snooping network traffic,
> modifying your local dns entry for digibug.com, disabling Javascript,
> using Firebug, curl, wget, or lots of other ways.  When I do this, I see:
>
> form action="http://www.digibug.com/dapi/order.php" method="post">
>     <input type="hidden" name="digibug_api_version" value="100"  />
> ...
> <input type="hidden" name="image_1"
> value="http://example.com/index.php/digibug/print_proxy/73db0f04da7cdf319c68ee11c5526a54"
>  />
>     </form>
>
> Now I've got the url to a full size image for which I have no
> permissions to see.  :-(
>
> I'm doing a pass over the Digibug module now and will fix this up along
> with some other stuff (the XSS wasn't fully closed, I'm going to
> simplify the UI, etc).
>
> -Bharat
>
> ------------------------------------------------------------------------------
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>


------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Chris F-2 wrote:

> Just an idea for this. Can a random string or something unique to the server
> for that image be added to this URL.
>
> That way the full image URL can be passed to a certain function, however a
> users/system cannot "guess" any other URLs of other images.
>
> The only way you can subvert the full permission of an image is by knowing
> basically the URL plus the 'key' to that individual image.
>
> So the url would be something similar to:
>
> http://example.com/gallery3/print_photo/35/12390239bbf32f
>
> And the random keys would not be sequential or guessable.

Are you suggesting a shared-secret solution?  That only works if you
share a secret with Digibug such that only your Gallery3 and Digibug
have a copy of the secret.  Currently, Digibug doesn't offer that type
of solution.  Each Gallery 3 install has its own unique key we could use
for this purpose, but Digibug would have to implement something on their
sude to support it.

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris F-2]

I wasn't thinking of that complex. Just a key that's unique to that image of that installation.

So for example:

key = md5(imageid + galleryuniqueid)

In this situation, the full image is still exposed, but it'll be only for that single image, not allow access to other full images.

It'll still fail your requirements, but it'll be limited to 1 image and not potentially others.

That means the url will be:

http://example.com/gallery3/print_photo/35/12390239bbf32f
http://example.com/gallery3/print_photo/36/534313901bfb1
http://example.com/gallery3/print_photo/37/1239bab9321vb

and not:

http://example.com/gallery3/print_photo/35
http://example.com/gallery3/print_photo/36
http://example.com/gallery3/print_photo/37

With the latter being guessable by a user.

Chris

Bharat Mediratta wrote:

Chris F-2 wrote:
> Just an idea for this. Can a random string or something unique to the server
> for that image be added to this URL.
>
> That way the full image URL can be passed to a certain function, however a
> users/system cannot "guess" any other URLs of other images.
>
> The only way you can subvert the full permission of an image is by knowing
> basically the URL plus the 'key' to that individual image.
>
> So the url would be something similar to:
>
> http://example.com/gallery3/print_photo/35/12390239bbf32f
>
> And the random keys would not be sequential or guessable.

Are you suggesting a shared-secret solution?  That only works if you
share a secret with Digibug such that only your Gallery3 and Digibug
have a copy of the secret.  Currently, Digibug doesn't offer that type
of solution.  Each Gallery 3 install has its own unique key we could use
for this purpose, but Digibug would have to implement something on their
sude to support it.

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Chris F-2 wrote:
> key = md5(imageid + galleryuniqueid)
...
> That means the url will be:
>
> http://example.com/gallery3/print_photo/35/12390239bbf32f
> http://example.com/gallery3/print_photo/36/534313901bfb1
> http://example.com/gallery3/print_photo/37/1239bab9321vb
...

I see.  The problem is that the "print" button has to provide a link to
this url, so each of these urls will be on display.  This means that
while I can't just put in arbitrary ids to grab your full size images, I
can just write a crawler to find these urls and then escalate each of
them into a full size url.  The end result is the same, as far as I can
tell-- I'll be able to circumvent permissions and grab your full size
images.

-Bharat

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris F-2]

Ah sorry, i thought this URL was passed behind the scenes and not public.

Scratch that idea then sorry.

Bharat Mediratta wrote:

Chris F-2 wrote:
> key = md5(imageid + galleryuniqueid)
...
> That means the url will be:
>
> http://example.com/gallery3/print_photo/35/12390239bbf32f
> http://example.com/gallery3/print_photo/36/534313901bfb1
> http://example.com/gallery3/print_photo/37/1239bab9321vb
...

I see.  The problem is that the "print" button has to provide a link to
this url, so each of these urls will be on display.  This means that
while I can't just put in arbitrary ids to grab your full size images, I
can just write a crawler to find these urls and then escalate each of
them into a full size url.  The end result is the same, as far as I can
tell-- I'll be able to circumvent permissions and grab your full size
images.

-Bharat

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Alec Myers]

I've been following this thread with great interest. What was the
G3-protocol-breaking method that you had in mind to get around this problem?
I can't see how you can reliably pass a private url (or, equivalently, the
image data itself) to digibug without either:

A shared secret with Digibug to verify the callback, or less convenient but
perhaps equivalently checking/verifying the IP address from which Digibug
tries to download the image data

OR -

A direct G3-server to Digibug protocol, i.e.  not passing the url via a
hidden field in a form in the user's browser.

-A

----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Chris F-2" <lists@...>
Cc: <gallery-devel@...>
Sent: Monday, June 29, 2009 5:02 AM
Subject: Re: [Gallery-devel] State of Digibug module


Chris F-2 wrote:
> key = md5(imageid + galleryuniqueid)
...
> That means the url will be:
>
> http://example.com/gallery3/print_photo/35/12390239bbf32f
> http://example.com/gallery3/print_photo/36/534313901bfb1
> http://example.com/gallery3/print_photo/37/1239bab9321vb
...

I see.  The problem is that the "print" button has to provide a link to
this url, so each of these urls will be on display.  This means that
while I can't just put in arbitrary ids to grab your full size images, I
can just write a crawler to find these urls and then escalate each of
them into a full size url.  The end result is the same, as far as I can
tell-- I'll be able to circumvent permissions and grab your full size
images.

-Bharat

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]



------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Alec Myers wrote:

> I've been following this thread with great interest. What was the
> G3-protocol-breaking method that you had in mind to get around this problem?
> I can't see how you can reliably pass a private url (or, equivalently, the
> image data itself) to digibug without either:
>
> A shared secret with Digibug to verify the callback, or less convenient but
> perhaps equivalently checking/verifying the IP address from which Digibug
> tries to download the image data
>
> OR -
>
> A direct G3-server to Digibug protocol, i.e.  not passing the url via a
> hidden field in a form in the user's browser.

We took the server<->server approach in G2 and while it worked, I never
really trusted it.  We had to write a lot of code on the backend to make
it robust, and then deliver the results to the user, etc.

We can sign it with a shared secret, but there's a logistical issue
which would require us to have something on the digibug side.

We could use a trusted 3rd party (eg: gallery.menalto.com) to do our
shared-secret encryption such that GMC proxies the request over to the
print service (not a fully baked idea).  This puts GMC in the critical
path, though which is not a great idea (and privacy users will be up in
arms).

IP locking might be the easiest approach.  We have Digibug give us their
set of legal IPs and burn it into G3 as a setting and only allow
print_proxy to receive requests from those urls.  It's easy, and
reasonably hard to spoof.  If the IPs change, we can put out a new
release.

-Bharat



------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]