When "read only" mode doesn't actually do anything and the system can be broken with four lines of code...



  • ...you're in for a long day.

    You may or may not have already heard of the "Fur Affinity" portal; in short, it's basically one of the largest online communities of members of the Furry Fandom (which you probably have heard of, given you're reading this on the Internet) and it's sort of a cross between art portal, online marketplace, social network and forums complex. You'd figure those guys would be pretty careful with their security measures, especially given how furries are basically the Internet's favourite punching bag, right?

     [url=http://eevee.livejournal.com/329409.html]Well[/url], you'd be [url=http://eevee.livejournal.com/329817.html]wrong[/url]. (Yes, it's a link to a livejournal blog, but bear with me, it's hilarious.)



  • Cross Site Request Forgery, that has always been my favourite exploit. It's very easy to code against, but complex enough that most people don't get it, and thus continue to serve the holes en masse.



  • I like how, in the first post, the admin kept on visiting the hacker's page, even after the hacker had first demonstrated that he was willing to use CSRF exploits on admins.



  • Wait a minute...did I read correctly? He created images with URLs for hiding comments? As in, comments were hidden via GET? I mean, at least they weren't being deleted (apparently), but Jesus...



  • @toth said:

    Wait a minute...did I read correctly? He created images with URLs for hiding comments? As in, comments were hidden via GET? I mean, at least they weren't being deleted (apparently), but Jesus...

    Yah this whole site sounds like Amateur Hour. This is also stuff that ASP.net basically will prevent for you, if you don't twiddle with the default settings. (I dunno what FA uses, but the URLs look like Ruby On Rails URLs.)



  • @blakeyrat said:

    @toth said:
    Wait a minute...did I read correctly? He created images with URLs for hiding comments? As in, comments were hidden via GET? I mean, at least they weren't being deleted (apparently), but Jesus...

    Yah this whole site sounds like Amateur Hour. This is also stuff that ASP.net basically will prevent for you, if you don't twiddle with the default settings. (I dunno what FA uses, but the URLs look like Ruby On Rails URLs.)

    I could understand (not forgive, but understand) if they merely forgot to make sure the request to hide a comment came from an authorized user if they had just done the fucking Web Design 101 measure of using POST.

    I also like that the "fix" was to require a user id...in the GET parameters...with no further authentication (although I guess it would be worse to have a user ID and password in the GET parameters.

    I like that site. It makes me feel like a brillant web developer in comparison.


  • @blakeyrat said:

    @toth said:
    Wait a minute...did I read correctly? He created images with URLs for hiding comments? As in, comments were hidden via GET? I mean, at least they weren't being deleted (apparently), but Jesus...

    Yah this whole site sounds like Amateur Hour. This is also stuff that ASP.net basically will prevent for you, if you don't twiddle with the default settings. (I dunno what FA uses, but the URLs look like Ruby On Rails URLs.)

    I popped into the comments in the LJ link... there's a guy in there named Witchiebunny who is claiming to represent FA in some capacity and (to be fair) doesn't seem very technical. He says they're constructing a new UI to address these issues without acknowledging that none of these issues involve the UI at all. Well, not unless you define "UI" in the broadest possible terms.



  • Replying to myself, sorry, but wow: in response to this, Witchiebunny says they're changing the code to check the Referer field before responding to any of those "this-should-be-a-POST" requests. Way to miss the point!

    Ok, I gotta stop reading about these goobers and go back to work...



  • Fur Affinity is a horrid example of legacy PHP code.

    It also helps that the development staff don't consider fixing bugs a priority. I discovered one exploit that renders a page unviewable, submitted a trouble ticket, and the response was "Well, the general consensus is It's fixed becuase it doesn't actually harm the site, nor can it harm the site. I just suggest you don't do it XD".

    A couple months later, a friend of mine (to whom I "accidently" let the exploit slip) took down a couple high-profile user pages using it.



  • @MiffTheFox said:

    It also helps that the development staff don't consider fixing bugs a priority. I discovered one exploit that renders a page unviewable, submitted a trouble ticket, and the response was "Well, the general consensus is It's fixed becuase it doesn't actually harm the site, nor can it harm the site. I just suggest you don't do it XD".

    Reminds me of Sony's "fix" on the 2010 "leap year" bug. Their fix consisted on sitting their asses and wait for "Feb 29, 2010" to end.


  • @danixdefcon5 said:

    Reminds me of Sony's "fix" on the 2010 "leap year" bug. Their fix consisted on sitting their asses and wait for "Feb 29, 2010" to end.
    Hard work pays off later - Procrastination pays off now!



  • @toth said:

    if they had just done the fucking Web Design 101 measure of using POST.
     

    Note that POST vs GET has very little bearing on anything in this context.

    XSRF attacks aren't any less possible against POST, they just require a hidden form and some javascript that .submit()'s them [which is surprisingly isn't affected by SOP at all] on a page controlled by the attacker instead of an <img>.



  • @Yukabacera said:

    bear with me
    Was that an intentional pun?



  •  @Zecc said:

    Was that an intentional pun?

    It just kinda snaked in.



  • @bdew said:

    @toth said:

    if they had just done the fucking Web Design 101 measure of using POST.
     

    Note that POST vs GET has very little bearing on anything in this context.

    XSRF attacks aren't any less possible against POST, they just require a hidden form and some javascript that .submit()'s them [which is surprisingly isn't affected by SOP at all] on a page controlled by the attacker instead of an <img>.

    I'm well aware that POSTS are not impossible, and I didn't mean to imply that POST would become a significant barrier. It would still be idiotic of them not to make sure the user was authorized to hide comments. It's the principle of the thing--GET should not be allowed to permanently change any state, which is what the hide-comments script does.



  • TRWTF is FurAffinity. Shit.



    Ignorant asswipish admins, plus craptons more exploits than JUST THAT.

    And to wrap it all up, most of the internal bugs are marked "Low priority" because they're not being exploited.

    And to clarify, FA is the DA of the furfags. Lulz is to be had.



  • @Indrora said:

    TRWTF is FurAffinity. Shit.



    Ignorant asswipish admins, plus craptons more exploits than JUST THAT.

    And to wrap it all up, most of the internal bugs are marked "Low priority" because they're not being exploited.

    And to clarify, FA is the DA of the furfags. Lulz is to be had.

    It's so bad, even FURRIES hate it!


Log in to reply