From: <sh...@um...> - 2010-03-30 18:24:47
|
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 <mar...@um...>: > On March 30, 2010 07:59 , "J.Lance Wilkinson" > <jlw...@ps...> 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 > mar...@um... > > > > ------------------------------------------------------------------------------ > 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 > Cos...@li... > https://lists.sourceforge.net/lists/listinfo/cosign-discuss > > !DSPAM:4bb2068e170902129515775! > > > > |