Hi Andrew, Hi Mark,
I agree with Mark that DoS'ing is the lesser of the two problems.
If the Flash utility has a shortcoming of not being able to pass
cookies over, is it possible to tie the utility in with AJAX
libraries, for e.g., to
do the POST requests for the uploads? Something like using XMLHTTP? Just
thinking out of the box.
Also, Mark, one question, do you really think an unauthenticated
upload can slip through? Per Lance's plan below, the javascript will
enable the second
move into the web server directory only if the user is authenticated.
So /tmp (the first target directory) has the ability to be DoS'd. If
the web-server uses /tmp in anyway, it will out of the water soon. So
let's say Lance
uses a different fiilesystem (/holding) for the first upload.
Then the javascript feature will only work if there is a valid Cosign cookie
in the browser. mod_cosign will not permit the upload if the user is
not authenticated. We are not considering compromises using brute
force attacks here, are we? That is a reality for sure, and if an
accoount is compromised, then your web-server will definitely be DoS'd.
What say?
Per Lance's example configuration:
--------------------------
<Location /tmp>
CosignAllowPublicAccess ON
(implicitly CosignProtected ON)
</Location>
He thinks this will:
1) allow the 1st POST from the FLASH utility uploading a file
to /tmp to be unauthenticated (public access)
2) allow the 2nd POST for the move operation which comes from
the swfupload javascript running within the browser and
needs to be authenticated (to /var/dam, which is by default
CosignProtected ON).
...
-------------------------
Only /tmp has the potential to be DoS'd/. Not the web-server directory.
(Sidenote - Using CAPTCHA with the Flash utility to make sure only
that anonymous evil humans and not bots are uploading might be something
to consider.)
Thanks.
-Shanti
Quoting Mark Montague <markm...@umich.edu>:
> On March 30, 2010 07:59 , "J.Lance Wilkinson"
> <jlw12+cos...@psulias.psu.edu> wrote:
>> This is EXACTLY what the 3rd-party vendor is hoping for, I think. A way for
>> them, who have a contractual obligation for their product to work
>> w/ CoSign for
>> us, to continue to use a feature they've added SINCE the contract was
>> negotiated that is incompatible w/ CoSign.
>>
>> I don't know if the potential for DoS's will sway people, but I'll
>> share that
>> w/ the team before proceeding.
>
>
> To me, a problem that is as big as -- if not bigger than -- the DoS
> concern is that since the Flash application won't be passing cookies to
> the web server, the web application won't know who uploaded what.
> Effectively, all uploads would be anonymous.
>
> Mark Montague
> ITS Enterprise Email& Collaboration Technologies Team
> The University of Michigan
> markm...@umich.edu
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Cosign-discuss mailing list
> Cosign-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
> !DSPAM:4bb2068e170902129515775!
>
>
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
