Stories
Slash Boxes
Comments

SoylentNews is people

SQL Injection Attacks Represent Two-Third of All Web App Attacks

posted by chromas on Saturday June 15 2019, @04:11PM   Printer-friendly
from the ';
dropâ €trou;# dept.

upstart writes for SoyCow4463:

SQL Injection Attacks Represent Two-Third of All Web App Attacks

For its "State of the Internet" report, Akamai analyzed data gathered from users of its Web application firewall technology between November 2017 and March 2019. The exercise shows that SQL injection (SQLi) now represents nearly two-thirds (65.1%) of all Web application attacks. That's up sharply from the 44% of Web application layer attacks that SQLi represented just two years ago.

Local File Inclusion (LFI) attacks, which, like SQLi, are also enabled by a Web application's failure to properly validate user input, accounted for another 24.7% of attacks. Together, SQLi and LFI attacks represented 89.8% of all attacks at the Web application layer over the 17-month period of Akamai's study.

[...] SQL injection errors and cross-site scripting (XSS) errors have topped, or nearly topped, the Open Web Application Security Project's (OWASP) list of top 10 Web vulnerabilities for more than a decade. Just this week, in fact, HackerOne published a report showing XSS errors to be by far the most common security vulnerability in Web apps across organizations. Both XSS and SQLi are well understood, and many researchers have catalogued the dangers associated with them for years.

The fact that so many Web apps still have them reflects the relatively scant attention paid to security in the application development stage, says Andy Ellis, chief security officer at Akamai. "It is not that the developers are making errors," he says. "It is system that we put them into that is dangerous."

[...] Akamai's data[pdf] shows most Web application attacks originate from inside the US and most targets are US-based as well. Of the nearly 4 billion application-layer attacks that Akamai counted over the 17-month period, some 2.7 billion targeted US organizations. Companies in the UK, Germany, Brazil, and India were also relatively heavily targeted. though nowhere nearly as much as US companies.

Original Submission

 
This discussion has been archived. No new comments can be posted.
SQL Injection Attacks Represent Two-Third of All Web App Attacks | Log In/Create an Account | Top | 50 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by stormreaver on Sunday June 16 2019, @01:17AM (6 children)

    by stormreaver (5101) on Sunday June 16 2019, @01:17AM (#856115)

    Or you can use prepared statements/parameterized queries, and solve the problem at its root.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by The Mighty Buzzard on Tuesday June 18 2019, @01:43PM (5 children)

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Tuesday June 18 2019, @01:43PM (#856976) Homepage Journal

    Too much repetitive typing. That's why functions exist.

    --
    My rights don't end where your fear begins.

    • (Score: 2) by stormreaver on Tuesday June 18 2019, @07:45PM

      by stormreaver (5101) on Tuesday June 18 2019, @07:45PM (#857152)

      You seem to think that the two are mutually exclusive, when they're not.

    • (Score: 2) by edIII on Thursday June 20 2019, @10:10PM (3 children)

      by edIII (791) on Thursday June 20 2019, @10:10PM (#858257)

      I do this all day long, and you've lost me a little. What do you mean?

      My lines of defense:

      1. I use parameterized queries. Don't even try to write SQL statements escaping all the quotes. That's what functions are for:)
      2. I get to define the datatype for each parameter, which acts as a light form of validation. If there is a way to convert it to the datatype, it will do that too.
      3. I also use UUIDs a lot for lookup tables used in dropdown boxes. So most things passed to me don't get through the light validation.
      4. For name fields where a single quote is appropriate, I use the HTML entity instead. Passing that back directly oftens renders it correctly on the page anyways. For other types of exports it's easy to reverse the process right before I export the data.
      5. For fields that shouldn't have a single quote anywhere, and/or a semi-colon, those get removed. Fields that should be alphanumeric get regex'd into alphanumeric. So many tard'd developers out there complain about '-' or '.' in phone numbers, when you just strip out everything that isn't a number and check length. I apply rules like this to all the fields before my SQL statements.
      6. Junk boxes, or basically a text field that has to accept all kinds of crap, get converted to BASE64

      What are you differently, that results in less typing but the same levels of defense against SQLi?

      --
      Technically, lunchtime is at any moment. It's just a wave function.

      • (Score: 2) by The Mighty Buzzard on Friday June 21 2019, @01:16AM (2 children)

        by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Friday June 21 2019, @01:16AM (#858362) Homepage Journal

        Well, it's not a strongly typed language but have a look here [github.com] for the very loosely typed perl we use on the site. We never use raw SQL if one of these is viable to use, which means we never have to remember to prepare a statement; manually escaping shit is right out. If we need a result that's going to be a hashref of arrays, we have to specifically ask for it. It's much more effective in say Rust where you can insist on a specific type of integer or string type but even just the loose typing of rehash is a hell of a lot better and safer than having to write out prepare, execute, fetch, finish every bloody time.

        --
        My rights don't end where your fear begins.

        • (Score: 2) by edIII on Friday June 21 2019, @01:50AM (1 child)

          by edIII (791) on Friday June 21 2019, @01:50AM (#858370)

          Thanks man. I'm always on the lookout for better and easier ways to do stuff like this. Not to mention more securely.

          --
          Technically, lunchtime is at any moment. It's just a wave function.

          • (Score: 2) by The Mighty Buzzard on Friday June 21 2019, @04:31AM

            by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Friday June 21 2019, @04:31AM (#858422) Homepage Journal

            Made perfect sense to me the first time I saw it. I mean, anything more than three lines you have to type repeatedly and nearly the same every time should probably be a function anyway, if only for legibility's sake.

            --
            My rights don't end where your fear begins.