mozilla :: #security

16 May 2017
16:11imaduemeHi again kang :)
16:11imaduemeI was playing around with https://testrp.security.allizom.org/ and after inspecting my userinfo I noticed that the scm_level_* groups aren't exposed in the list of ldap groups I belong to. I was wondering if it is possible for those to be exposed; my team over at #conduit would like to rely 100% on Auth0 instead of having to make an additional query to LDAP.
16:11kangimadueme: are you in the group?
16:12imaduemekang: I have scm level 1 so I should be, I also confirmed with glob and mcote that they could not see their scm levels
16:13imaduemeJust wondering if its possible, otherwise we can always fall back to querying LDAP :)
16:13kangno, it'll be fixed if its a bug :)
16:14imaduemecool, glob also mentioned something about the scm_levels being a posix group? We're not sure if that really matters or not
16:16kangit probably is the reason
16:16kangbut then we've to fix that :)
16:18imaduemekang: awesome, I'm happy to file that bug, but otherwise I'll leave it to you. In the meantime we'll assume that Auth0 will provide the scm levels. If you file it then please do cc me, thank you!
16:24kangimadueme: https://github.com/mozilla/iam-project-backlog/issues/144
16:25imadueme\o/
16:38davidwalshkang: andrew: Did you encounter any "returnTo" param problems during logout?
16:38davidwalshhttps://irccloud.mozilla.com/file/UgBXV5Yw/LogoutError.png
16:38andrewYou don't have your logout URL configured in auth0 client
16:39davidwalshI do though :/
16:39davidwalshhttps://irccloud.mozilla.com/file/k6zFJyTN/LogoutURLs.png
16:39davidwalshI see this (https://auth0.com/forum/t/logout-redirect-misconfiguration-in-the-system/2949) but I'm not finding where I configure that
16:40kangdavidwalsh: auth0 generally indicates what went wrong in logs as well - since this is your own account only you can see that though
16:46andrewAre you using the redirect logout?
16:47andrewI just do this in flask-pyoidc
16:47andrewhttps://irccloud.mozilla.com/pastebin/QNbiFTut/
16:47andrewThe logout decorator works server side
17:04kangdavidwalsh: note logout is often not implemented, which is fine as long as you have session management/refresh done right (people can log out via dashboard)
17:04davidwalshkang: Is it cool if we pass along client_id? Passing that makes logout work properly
17:05davidwalshkang: Also, have you tested hitting the "/logout" URL when the user isn't logged in? I get an error here, may be a library issue
17:07kangdavidwalsh: client id is public
17:07kangdavidwalsh: nope, not using it yet for this library on my side
18:34CymewI asked this on #mozilla@freenode but was directed here.
18:34CymewThis CVE-2016-8743 is affecting apache servers, and could potentially cause all firefox browsers to fail (https://httpd.apache.org/security/vulnerabilities_24.html) if they send the wrong whitespace in the request. Anyone knowledgable who can say if firefox could fail against a server patched against that CVE?
19:49Caspy7I always seem to fail or get "shot down" when this comes up... Is being strict about MIME type and not using file extension a security consideration?
19:49Caspy7if so, can you explain why/how?
19:49Caspy7like an example
19:52jwhitlockThere was an exploit against IE 7 based on it trying to figure out the page type vs trusting the headers https://en.wikipedia.org/wiki/Content_sniffing
19:54dveditzCaspy7: on an actual file we don't have a mime type, so we guess by extension
19:55Caspy7jwhitlock: what about the argument of falling back to the extension?
19:55dveditzbut yes, not using the MIME type sent by the server can be a security problem on the web
19:55Caspy7dveditz: I have someone in #firefox complaining that a certain file always ask what they want to do with it even thought it's .wmv
19:56dveditzwhether you &quot;sniff&quot; the content of the file (found &#39;<&#39; in first 200 bytes, probably HTML) or use the extension
19:56Caspy7so the question is, why not fall back to the extension and rely on that
19:56dveditza &quot;file&quot; on disk, or saving one from the web?
19:56Caspy7on the web
19:56dveditzsaving from the web we always ask because _that_ can be an attack, too
19:56Caspy7ok, well that&#39;s basically the argument that I&#39;ve been using, but apparently I need more compelling examples b/c I don&#39;t have any
19:57dveditzlet&#39;s say we always opened .docx files in Word -- the first word macro virus to come around and the internet is toast
19:57Caspy7they always have counter arguments about why it should be safe
19:57dveditzsure, which is why we have a &quot;always do this for this type&quot; checkbox
19:57dveditzif it&#39;s not remembering their choice maybe one of their profile files is corrupt
19:58dveditzmimetypes.rdf, I think
19:59Caspy7dveditz: I was under the impression that we never remember &quot;always do this&quot; if there is no MIME type
19:59Caspy7or...maybe we removed that option...
19:59dveditzyou mean just a missing Content-Type header?
19:59dveditzhm, would have to look that up
19:59dveditzI thought we fell back to extensions in that case (for saving)
19:59jwhitlockyes, that would make sense to me - if the server didn&#39;t set Content-Type, then treat it as an unknown file
20:00jwhitlockget the whole thing to disk, then let the OS figure out the file type
20:01dveditzyou&#39;re right, looks like we store by mime type or protocol
20:02dveditzyup, save to disk, let the OS figure it out
20:04Caspy7well, I&#39;ve seen this complaint several times before
20:04Caspy7people wondering why they get badgered repeatedly when downloading the same file type
17 May 2017
No messages
   
Last message: 6 days and 7 hours ago