• FooBarrington@lemmy.world
    link
    fedilink
    English
    arrow-up
    30
    arrow-down
    1
    ·
    1 year ago

    That’s… Surprising. If you’re doing things right, double quotes should be no trouble at all:

    • HTTP requests have simple, automatic encoding
    • SQL queries with prepared statements don’t need any special handling for double quotes
    • Rendering the data should happen with proper escaping etc.

    They are usually only trouble if you’re doing SQL queries wrong (concatenation etc.) or if you’re not escaping your output.

    • Alien Nathan Edward@lemm.ee
      link
      fedilink
      English
      arrow-up
      20
      ·
      edit-2
      1 year ago

      The issue is the filter that we’re using to avoid multiple encoding attacks de-escapes everything via multiple rounds, then tries to pass it to the next layer of filtering with the de-escaped request body as a json string. Your absolutely right that this is a silly way of doing it, but sometimes we have to live with decisions that were made before we were onboarded to a project. In this particular case, I pushed to improve the filters but all our PO heard was “spend development time weakening security” and at the end of the day they decide what to do and we do it.

        • Alien Nathan Edward@lemm.ee
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          You should tell that to OWASP then, they wrote it. org.owasp.esapi 2.5.2.0, class is Encoder, method is canonicalize(String, bool, bool)

          • WarmApplePieShrek@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            This method is a band-aid patch when your downstream code is all messed up and you can’t fix it. Instead of treating the input string correctly, it just removes anything that might possibly trigger some vulnerability in wrong code.