SQL Erection


  • Discourse touched me in a no-no place

    So my company's product is written in a language called Progress. That's not TRWTF, because it's powerful, and adequate to our needs. We also have an adjunct web app, written in Classic ASP long before I got there. In the last few years, three separate customers have done security audits, and they all come up dinging us for SQL injection vulnerabilities.

    I keep saying "Really? Show me one, then!" Because I don't think the ODBC driver actually HAS that vuln, because I actually tried a couple of simple classic ones, and they just failed. It probably helps that the SQL implementation is somewhat half-assed, so some methods will actually just result in an error.

    I actually want to see a successful, trivial injection so I can mitigate against it. (parameterized queries, as far as I can tell, won't work with classic asp, and convincing them to rewrite in asp.net isn't in the cards.)



  • [code]
    DEFINE VARIABLE w AS HANDLE NO-UNDO.

    CREATE WINDOW w ASSIGN
    WIDTH = 50
    HEIGHT = 5
    MESSAGE-AREA = FALSE
    STATUS-AREA = FALSE.

    CURRENT-WINDOW = w.

    DEFINE BUTTON btnOK LABEL "OK" SIZE 12 BY 1.2.
    FORM
    "Hello World!" VIEW-AS TEXT AT COL 20 ROW 2
    btnOK AT COL 20 ROW 4
    WITH FRAME f SIZE 50 BY 5 NO-BOX THREE-D.

    VIEW FRAME f.
    ENABLE btnOK WITH FRAME f.
    WAIT-FOR "CHOOSE" OF btnOK.
    DELETE OBJECT w.
    [/code]
    Why does this look like SQL turned into a GUI language?


  • Discourse touched me in a no-no place

    Because it started life as a DML/4GL and morphed into a GUI language?



  • Time to move out of the dorm.



  • What?


  • Discourse touched me in a no-no place

    He thinks he's funny because I said that to him on another thread in a context where it actually made sense.


  • Discourse touched me in a no-no place

    Btw, @blakeyrat, it was funny when I said it because it's the kind of thing someone in a dorm would plausibly complain about. Although I actually assume you live in an apartment building and a neighbor's got the volume up too loud.



  • This topic leaves significant want of actual WTF. Maybe another category?



  • @Matches said:

    This topic leaves significant want of actual WTF. Maybe another category?

    Anything involving AUDITORS or REGULATORS automatically involve enough WTF to qualify for this category. 14 years of this and I have yet to have ONE encounter with these that didn't involve some kind of WTF somewhere.

    My latest one from the last audit? Paraphrased: "Someone needs to parse through your VoIP logs every day to see who's calling who and flag any suspicious calls." Say WHAT?

    1. Give me the budget for an FTE.
      1A) ...and the budget to replace him every 3 months, as anyone who takes that kind of job will want out in a week to preserve their sanity.
    2. WTF are we accomplishing here? I walk over to Joe's desk, CALL 911-PR0N, shows up on Joe's log, Joe gets disciplined. Good job.
      2A) Not to mention we're in the age of CELL PHONES. Anyone doing something like a job search on company time = not likely to use company phone which may be recorded. Duh.

    We're still waiting on the 'official' report to see if they removed that 'recommendation'... -_-



  • OK, except he says customers, not auditor or regulator.



  • @Matches said:

    OK, except he says customers, not auditor or regulator.

    Actually, he says

    @FrostCat said:

    three separate customers have done security audits

    So one of the following must be true:

    1. The customers hired security auditors
    2. The customers are security auditors
    3. The customers are doing things they are not qualified to do because they found some words that sounded fancy in a book about computering


  • #3 seems the most likely based on the lack of being shown how he's got a sql injection flaw that they describe.

    Thanks, discourse.


  • Discourse touched me in a no-no place

    @redwizard said:

    Paraphrased: "Someone needs to parse through your VoIP logs every day to see who's calling who and flag any suspicious calls." Say WHAT?

    That's probably to detect the case where someone hacks into your PBX and uses it to redirect calls to Nigeria (or some other expensive overseas location). That gets expensive for you, fast. An individual employees phone misuse probably doesn't even register on that scale.



  • I see two possibilities here:

    1. Your customers are the WTF because they think they found a vulnerability when there is none. However, I don't know how likely it is that three different customers come up with the same false positive independently of each other (unless you have hundreds of other audits that didn't find a problem).

    2. You are the WTF for refusing to look into a security issue. SQL Injection vulnerability is not a bug in the database connection driver, but a wrong way of building requests in the application code. It does not need a working exploit to prove the existence of a vulnerability. Sometimes, a vulnerability isn't even exploitable because of some lucky coincidence in the surrounding application code, but that luck may turn every time you make a change. So stop complaining and sanitize your database inputs. (insert xkcd reference here)



  • @FrostCat said:

    Because I don't think the ODBC driver actually HAS that vuln, because I actually tried a couple of simple classic ones, and they just failed.

    ODBC with ADO doesn't even protect parameterized queries from SQL injection.



  • This sounds like a Loan Origination System I used to have to deal with. If I'm being honest with myself, the major issues were with the company that wrote it and our in house dev team that rewrote portions of it- but because it was Progress/4GL, I still shudder when I see that.

    Did they just say "You have SQL Injection Vulnerabilities"? Seems odd, normally I'd expect it to be "You have a vulnerability on page X textbox Y". Now those reports may or may not be accurate, IME, but at least they are easy to check.



  • @Jaime said:

    ODBC with ADO doesn't even protect parameterized queries from SQL injection.

    Mind explaining to me how this steaming pile of WTF comes to be? Does ODBC/ADO really hand-roll fake-parameterization, ignoring whatever actual parameterization facilities the underlying database driver provides?



  • @dkf said:

    That's probably to detect the case where someone hacks into your PBX and uses it to redirect calls to Nigeria (or some other expensive overseas location). That gets expensive for you, fast. An individual employees phone misuse probably doesn't even register on that scale.

    THAT would have at least been a plausible explanation (thank you for adding some sanity here), but all they said was "we should watch it."

    If they did come up with that, I'd come back with flagging international calls/976 calls/etc. and sending alerts as the solution, NOT hiring an FTE to watch it!!



  • @Barbaz said:

    However, I don't know how likely it is that three different customers come up with the same false positive independently of each other (unless you have hundreds of other audits that didn't find a problem).

    Very likely.

    In our last vulnerability assessment, they brought in a guy that knew what he was doing (woot!) He could tell the difference between what truly was a vulnerability (ONE found & was already mitigated) vs. what might be a vulnerability and turned out to be a false positive (all others fell into this category).

    Every other one we've had before just listed what their tools said were possible vulnerabilities. That gets old, even if there's only a few.



  • @tarunik said:

    Mind explaining to me how this steaming pile of WTF comes to be? Does ODBC/ADO really hand-roll fake-parameterization, ignoring whatever actual parameterization facilities the underlying database driver provides?

    It's driver-specific and I'm currently unable to reproduce it, so maybe it's been fixed since I last ran into it about five years ago.



  • @redwizard said:

    Every other one we've had before just listed what their tools said were possible vulnerabilities. That gets old, even if there's only a few.

    Last time I had a security scan, it always said SQL injection was a possible vulnerability because the scan tool couldn't verify if it had or hadn't injected SQL. It was really annoying that we could never get it off the report and some pinhead always made us go verify it whenever a scan was done.



  • Really? "Simplify software development"? Since most of the work of a software developer is thinking, rather than typing, where does Progress fit? And compare the example (show a dialog with "hello world" and a button") to this:

    <script type="text/javascript">alert('hello world')</script>
    

    There, about 1/20th the number of characters.


  • Discourse touched me in a no-no place

    @cdosrun1 said:

    Did they just say "You have SQL Injection Vulnerabilities"? Seems odd, normally I'd expect it to be "You have a vulnerability on page X textbox Y". Now those reports may or may not be accurate, IME, but at least they are easy to check.

    I actually kinda like using Progress, but I may not stay with it forever.

    They actually weaseled, in every case. "There may be a SQL Injection vulnerability on <some random page>".


  • Discourse touched me in a no-no place

    @ben_lubar said:

    So one of the following must be true:

    The customers hired security auditors
    The customers are security auditors
    The customers are doing things they are not qualified to do because they found some words that sounded fancy in a book about computering

    As best as I can tell, these customers basically hired one of these companies that claims to do intrusion testing. They all tried to justify their salaries by noticing some trivial actual issues, and one or two POTENTIALLY DANGEROUS MAJOR VULNERABILITIES.

    Bear in mind we're talking about a site where you can do crap like request PTO and the like. The actual worst thing an exploited vulnerability could do would be to see someone else's pay check.

    Which isn't to say stuff like that shouldn't be fixed--it should, but I just get a kick out of the usual MAJOR HYPE with tiny "may not actually be present" disclaimers.



  • @FrostCat said:

    I actually kinda like using Progress, but I may not stay with it forever.

    They actually weaseled, in every case. "There may be a SQL Injection vulnerability on <some random page>".

    Hmm. I used to deal with something similar on, I think, Nessus scans.

    Automated tool that scans servers/workstations/etc on remote workstations. The semi-yearly audits would be be run by someone in a different state, and every single machine would be flagged as "Possible Physical Security Risk"- Because the automated tool couldn't determine if we actually had the appropriate security doors, screen privacy guards, and labels required for that class of machine.

    Kind of a cop out for the security tool- If you can't actually check if a vulnerability exists or not, just flag the machine as vulnerable, never mind the poor guy who has to address this perceived vulnerability on a few hundred machines.

    I might be unfairly blaming Nessus- No chance I remember the specific tool involved now. But they have probably done something similar.



  • @Jaime said:

    It's driver-specific and I'm currently unable to reproduce it, so maybe it's been fixed since I last ran into it about five years ago.

    Do you recall which driver?

    I hope we don't have to take this discussion to the IHOC...



  • @tarunik said:

    Do you recall which driver?

    It was definitely the SQL Server ODBC driver. I used to use it as one of the reasons to use the OLEDB provider.



  • . . . <wtf.>


Log in to reply