Swiss banking software has Swiss cheese security, says Rapid7 Rapid7 has gone public with news of an e-commerce SQL injection vulnerability, saying it couldn't raise a response from the vendor. The software in question, SmartVista, is an e-commerce and financial product from BPC Banking, and in this post, Rapid7 says it told the company about the issue back in May 2017. The US CERT …
> The US CERT Coordination Centre and SwissCERT joined the security company's effort to alert the Switzerland-based vendor in July and August, ahead of yesterday's disclosure
Two major government agencies couldn't contact a bank about security... so why do they still have a business licence?
Bobby Tables notwithstanding, haven’t there been enough high profile incidents to highlight the risk of SQL Injection?
I don’t know what’s on the back end, but all modern databases support Prepared Statements. Three extra lines of code is all it takes to dramatically reduce the risk.
Was the developer called Rip Van Winkle?
How is SQL itself still a thing?
I mean, this is a language that is roughly the equivalent of COBOL. It's been invented almost forty years ago, on the mistaken assumption that programming languages should look like English. Its syntax completely obfuscates the execution logic.
So now we have computers concatenating strings to build SQL statements, which are sent to other computers, only to be parsed at the other end, which is pretty sad; and when you think of it, that's the only reason SQL injections are even possible in the first place.
I yearn for a modern language based on the abstract concepts underlying the execution tree. The only way I can explain we don't have such a language is that by the time engineers understand the execution tree, they already have Stockholm syndrome about the syntax.
Actually SQL is not that bad and it definitely is not equivalent of COBOL. The problem is not SQL; it is programmers who think that building SQL programmatically by string concatenation is acceptable. It is not and never was. That's what stored procedures with parameters passing are for, or failing that pre-compiled statements, but of course that requires a little more varied code on the caller side. In effect there are two programming models here: 1) actual database queries and manipulation language in SQL and 2) database interface with procedures/pre-compiled statements, parameters etc. required to use 1) from other languages.
Programmers often perceive 2) as an optional element but it is not and as you have demonstrated above, it is easier to rant about 1) than learn to use it properly.
FWIW I do not use SQL now and have not used it for years, but frankly how can anyone aspire for "better languages" without understanding of what went before?
The problem with stored procedures is that they are vendor specific where as plain 'ol SQL is largely cross RDBMS compatible.
Sure you can use an ORM wrapper but these come with their own challenges.
In agree though that if we had a clean slate to redesign SQL, there is no way we would interleave the instruction and data elements or allow inline constant expressions that drive people to try and build up the command with string concatenation.
I mean, this is a language that is roughly the equivalent of COBOL. It's been invented almost forty years ago, on the mistaken assumption that programming languages should look like English. Its syntax completely obfuscates the execution logic.
As usual with knee jerk ageism, you miss the point. The new hotness in web monkey land is GraphQL which makes everything look like JSON, conveys even less about execution strategy than SQL (at least you can infer something from JOIN) and only obstructs nefarious injection by virtue of the fact that no RDBMS understands it natively (yet).
The problem isn't the query language, it is the vast attack surface you open up when you allow a front end to send commands either directly to an RDBMS or via middleware built by people who only understand ORMs and therefore can't code triggers and stored procedures effectively.
SQL being roughly equivalent to COBOL
You know...
If you're not educated on a subject, please don't believe you're obliged to show the world how ignorant you are.
Your statement displays your closed mindedness towards learning. As if COBOL hasn't been through any changes since 1959.
I guess you probably believe Microsoft DOS or UNIX hasn't had any changes since 1980.
Not all is lost though; I do believe the food industry can still use you.
This post has been deleted by its author
"one could craft a series of database queries to ask true/false statements such as 'Does the first character, of the first row, in the user’s column start with a?' "
Or one could ask: 'Is the first character, of the first row, in the user’s column less than n?' and do a binary chop in far less time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
