tag:blogger.com,1999:blog-8508344381521415235.post831804284196508031..comments2024-02-10T02:19:53.889-08:00Comments on Egor Homakov: Evolution of Open Redirect Vulnerability.homakovhttp://www.blogger.com/profile/10492045246792330280noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-8508344381521415235.post-28797855553374681372015-06-26T12:49:32.415-07:002015-06-26T12:49:32.415-07:00Some libraries aren't that secure. I wrote an ...Some libraries aren't that secure. I wrote an article about how Python module UrlParse fails to reconstruct urls leading to an open redirect.<br />http://yassineaboukir.com/blog/python-module-urlparse-improper-input-validation-leads-to-open-redirect/Yassin ABOUKIRhttps://www.blogger.com/profile/17490952387323503755noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-89961746296931274872015-02-07T15:51:25.837-08:002015-02-07T15:51:25.837-08:00Fair points. Also internal/relative URL's can ...Fair points. Also internal/relative URL's can also be external-URL's. there is this specific example, take \%09/@example.com if the filters (mostly like Facebook's linkshim) trying to detect // or \/ that should bypass it. worked for me in multiple-cases. Paulos Yibelo Mesfinhttps://www.blogger.com/profile/15352267161194582479noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-36760718369802239102014-02-14T19:08:30.752-08:002014-02-14T19:08:30.752-08:00in perfect world everybody follows RFC, but not he...in perfect world everybody follows RFC, but not here)homakovhttps://www.blogger.com/profile/10492045246792330280noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-86859278140327753202014-02-14T08:26:03.328-08:002014-02-14T08:26:03.328-08:00If what you respond with in a Location: header is ...If what you respond with in a Location: header is anything but a full absolute URI (protocol and all), you're doing it wrong. (see RFC 2616)<br /><br />If your framework doesn't allow you to know inside the implementation of /login?next_url=/messages what your full URI is, your framework is doing it wrong.<br /><br />Yes, browsers accept all sorts of things in Location: headers. That doesn't mean it isn't sloppy (and, as you show, vulnerable) practice to use anything but an absolute URI.Anonymoushttps://www.blogger.com/profile/16496672682897819186noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-35749375408536100652014-02-11T20:22:12.298-08:002014-02-11T20:22:12.298-08:00never saw filter_var used for this purpose. Overal...never saw filter_var used for this purpose. Overall, PHP users don't validate anything.homakovhttps://www.blogger.com/profile/10492045246792330280noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-76476811939168306352014-02-11T05:54:53.923-08:002014-02-11T05:54:53.923-08:00PHP documentation for parse_url states that the fu...PHP documentation for parse_url states that the function is not meant to validate urls.<br /><br />The core filter extension, however, seems to behave correctly:<br /><br />var_dump( filter_var ("///host.com", FILTER_VALIDATE_URL) ); // bool(false)<br />var_dump( filter_var ("/\host.com", FILTER_VALIDATE_URL) ); // bool(false)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-81729770919603158122014-02-08T22:36:22.421-08:002014-02-08T22:36:22.421-08:00yes, here they areyes, here they arehomakovhttps://www.blogger.com/profile/10492045246792330280noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-22534324559329591112014-02-08T10:07:43.022-08:002014-02-08T10:07:43.022-08:00Found them:
https://bugzilla.mozilla.org/show_bug....Found them:<br />https://bugzilla.mozilla.org/show_bug.cgi?id=936869<br />https://code.google.com/p/chromium/issues/detail?id=317467Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-24230773291151547482014-02-08T01:36:52.336-08:002014-02-08T01:36:52.336-08:00Link to the issues in both browsers' bug track...Link to the issues in both browsers' bug trackers?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-66993053269798846132014-02-07T22:21:49.964-08:002014-02-07T22:21:49.964-08:00Node just told you /x.com is a path. This is a bug...Node just told you /x.com is a path. This is a bug because this is *not* a path, and if you respond with Location: ///host.com it will load host.com<br />homakovhttps://www.blogger.com/profile/10492045246792330280noreply@blogger.comtag:blogger.com,1999:blog-8508344381521415235.post-88782798466902193792014-02-07T18:44:15.906-08:002014-02-07T18:44:15.906-08:00Or you could, y'know, normalize the path if it...Or you could, y'know, normalize the path if it is a local path.<br /><br />Seems silly to just check if it is a local path without actually making sure the path is remotely sane. `require('path').normalize('///x.com')` in node.js gives me `/x.com`, which is probably what we want, no?Anonymoushttps://www.blogger.com/profile/16142713386882965002noreply@blogger.com