As shown in this article, DB2 might be vulnerable to SQL Injections:
* Potential SQL injection if X, Y or Z host variables come from untrusted input
STRING "INSERT INTO TBL (a,b,c) VALUES (" X "," Y "," Z ")" INTO MY-SQL.
EXEC SQL PREPARE STMT FROM :MY-SQL END-EXEC.
EXEC SQL EXECUTE STMT END-EXEC.
My question is if native IMS commands are vulnerable of this kind (or similar) injections? For instance, by imputing malicious input in the ISRT DLI command.
It depends on how you plan to access the IMS database.
Quoting from an IBM document.
The SQL statements that you issue through the web interface or the
ISPF interface are executed as IMS application programming API in the
IMS SPUFI application program in z/OS®. You can select COBOL or Java™
for the language environment to execute SQL statements.
If you use SQL, you're possibly vulnerable to SQL injection.
If you use native IMS commands, probably not. But it's still a good idea to sanitize your inputs, even for native IMS commands.
Yes, all SQL databases that support runtime parsing of an SQL query string are susceptible to SQL injection.
SQL injection is not a flaw in the database technology, it's a flaw in the client code you write that builds the SQL query string.
I’m a member of the IBM IMS team.
IMS DL/I calls are not dynamic and for that reason are not susceptible like SQL calls. There is no injection risk for CALL xxxTDLI IMS APIs. That being said, a COBOL program can open up risk by allowing input to the program to influence the SSA list or IOAREA parameters being passed to the xxxTDLI. So, secure engineering practices should be followed while programing against these interfaces.
No, an IMS DL/I database doesn't parse the record at all. See it as an early version of a NoSQL database like Cassandra. The segment key is parsed as a binary value but you can't do injections like in a SQL database.
And depending on the skill of the programmers/IMS-admins the attack vector might be closed by limiting the range of available CRUD actions that are available for the program using the PROCOPT's of the PCB in the PSB.
Most IMS-system+DB2 use static SQL's so the statement is already prepared and not vulnerable to SQL injection attacks.
Related
I am working on writing a Spring Java program accessing data from Athena, but I found that Athena JDBC driver does not support PreparedStatement, does anyone have idea about how to avoid SQL injection on Athena?
Update: I originally answered this question in 2018, and since then Athena now supports query parameters.
Below is my original answer:
You'll have to format your SQL query as a string before you prepare the query, and include variables by string concatenation.
In other words, welcome to PHP programming circa 2005! :-(
This puts the responsibility on you and your application code to ensure the variables are safe, and don't cause SQL injection vulnerabilities.
For example, you can cast variables to numeric data types before you interpolate them into your SQL.
Or you can create an allowlist when it's possible to declare a limited set of values that may be allowed. If you accept input, check it against the whitelist. If the input is not in the allowlist, don't use it as part of your SQL statement.
I recommend you give feedback to the AWS Athena project and ask them when they will provide support for SQL query parameters in their JDBC driver. Email them at Athena-feedback#amazon.com
See also this related question: AWS Athena JDBC PreparedStatement
Athena now has support for prepared statements (this was not the case when the question was asked).
That being said, prepared statements aren't the only way to guard against SQL injection attacks in Athena, and SQL injection attacks aren't as serious as they are in a database.
Athena is just a query engine, not a database. While dropping a table can be disruptive, tables are just metadata, and the data is not dropped along with it.
Athena's API does not allow multiple statements in the same execution, so you can't sneak a DROP TABLE foo into a statement without completely replacing the query.
Athena does not, by design, have any capability of deleting data. Athena has features that can create new data, such as CTAS, but it will refuse to write into an existing location and cannot overwrite existing data.
This is a hybrid question & public service announcement. The basic question is whether there are convenient and/or efficient workarounds to the limitations listed below. I spent half the morning discovering that one cannot just transplant SQL code from Access to Matlab. I've boiled it down to 3 points so far.
Can't use double quotes in SQL statements to avoid collision with
Matlab's string delimiter. The Matlab code for the SQL code strings
can become quite complicated, especially if the SQL strings already
use repeated single-quotes to represent a single quote within a
string constant.
Must always specify a source table from which to query. What won't
work is "SELECT #2015-07-28#". One basically needs to create a 1-row dummy table.
Must always select at least one field in the table being queried.
An asterisk does not seem to suffice.
The above limitations do not exist when submitting SQL code using the Access Query Designer (either in SQL 92 mode or not), nor do these limitations exist when submitting SQL code using VBA via CurrentProject.Connection.Execute.
Hopefully, this saves someone else some time in learning about these differences. And if anyone has found a workaround, that would be appreciated. Note that the above is in the context of using the JDBC/ODBC bridge (3rd of 3 illustrated configurations in the drivers documentation. The database toolbox documentation for directly connecting to an Access file using code (rather than setting up a data source using the GUI) only describes a code pattern that uses the JDBC/ODBC bridge. This is described in Example "Connect to Microsoft Access Using a File DSN" in the "Connect to database" page. I'd like to stick to this approach because I want to quickly be able to directly specify the source *.accdb file without jumping through GUI hoops of setting up a data source.
I've posted this to:
Stack overflow
Usenet
While I have not connected Matlab to Access, I have connected Access databases to PHP, Python, SAS, R, even Excel without any issues with quotes or asterisk. As for the needed source table in queries that is simply due to the Jet/ACE SQL dialect as each dialect have their particular rules. But your query above should work for one-row, one-column output of such date. SQL Server does not require a source table but Oracle does. Access dates are in the MM/DD/YYYY format, requiring # in conditional statements. MySQL use dates in YYYY-MM-DD format, requiring single quotes.
Are you using Windows installed Jet/ACE ODBC drivers? Do note these drivers are softwares external to any application (not part of Access) and can be used by any client interfacing to any data source. Aside - many are not aware that Access' backend database engine, Jet/ACE is actually a Windows technology and not restricted to Access; PC users without Access installed can still use this engine. Hence, connection strings are standard across ODBC calls. And as I see you can apply same principles to Matlab database connections.
With that said, my suggestions/workarounds:
properly learn the SQL dialect for connecting database and check if query runs; even optimize or re-write as needed
try escaping various punctuation not compliant in Matlab strings or use the ASCII counterparts: chr(34) for double quote; chr(39) for single quote; chr(42) for asterisk.
if select statements are limited in Matlab strings, create a temp table from query (use make-table query SELECT * INTO newtable FROM query outside of Matlab), then connect to this new table
use intermediary coding language (VBA, Python, C#) by user trigger or
command line to connect to database and export needed dataset, then
automate Matlab to import
export query to flatfile format (csv, txt, etc.) for Matlab import
I want to know what PostgreSQL functions are.
When do I have to write them?
How can I write them?
And how can I call them?
Definition, from wikipedia:
A stored procedure is a subroutine available to applications that
access a relational database system.
Advantages of stored procedures in general, from wikipedia:
Overhead: Because stored procedure statements are stored directly in
the database, they may remove all or part of the compilation overhead
that is typically required in situations where software applications
send inline (dynamic) SQL queries to a database. (...)
Avoidance of network traffic: A major advantage with stored procedures
is that they can run directly within the database engine. In a
production system, this typically means that the procedures run
entirely on a specialized database server, which has direct access to
the data being accessed. The benefit here is that network
communication costs can be avoided completely. This becomes
particularly important for complex series of SQL statements.
Encapsulation of business logic: Stored procedures allow programmers
to embed business logic as an API in the database, which can simplify
data management and reduce the need to encode the logic elsewhere in
client programs. (...)
Delegation of access-rights: In many systems, stored procedures can be
granted access rights to the database that users who execute those
procedures do not directly have.
Some protection from SQL injection attacks: Stored procedures can be
used to protect against injection attacks. Stored procedure parameters
will be treated as data even if an attacker inserts SQL commands. (...)
In PostgresSQL stored procedures are called user defined functions.
Definition example:
CREATE FUNCTION somefunc(quantity integer) RETURNS integer AS $$
DECLARE
myvariable integer := 2;
BEGIN
RETURN quantity * myvariable;
END;
$$ LANGUAGE plpgsql;
(You can use other languages to define stored functions in PostgreSQL)
Calling example:
SELECT somefunc(100);
More info: http://www.postgresql.org/docs/9.1/static/server-programming.html
PostgreSQL runs stored procedures in more than a dozen programming languages, including Java, Perl, Python, Ruby, Tcl, C/C++, and its own
PL/pgSQL, which is similar to Oracle's PL/SQL.
The use of stored procedure depends on your needs and depends on the logic of your program, in my opinion stored procedure are useful only in some cases and not ever...
I've used stored procedure in a multi database server application, in this case the use of stored procedure could be extremely useful for example in the case you have a query that need to be modified for run in another database server type, in that case you can write a stored procedure in each database server and call it from your program being sure that it run and retrieve the wanted resultset without any changes in the client code.
To learn how to create stored procedure in PostgreSQL refer to this page of the documentation.
the main advantage is reducing network traffic overhead. Stored procedure is almost same (not exactly) as business logic or logic tire. Its main advantage is making dynamic enterprise application.You can find 100s of good product failed just because lack of dynamic database structure. Stores procedures,Functions,Triggers,Sequences,indexes and relational nature of database are the real keys to create great applications.My company always try to reduce client side logic layers with the help of stored procedures. Most of the critical logics are store in stored procedures which makes programmers and testers happy and meet their timelines.
We have a software solution that involves syncing some data between a Progress database and SQL server. Unfortunately, we do not have any Progress gurus in house, so I'm working kinda blind here and would welcome any advice that is on offer.
For the workflow that is already in place, what would work very well for us is the ability to do an external call to insert a row into an SQL database from an within ABL procedure's 'for each' loop.
Is anyone able to direct me to any code snippets or articles that might help me achieve this?
Many thanks,
In case your SQL database is MS SQL Server, you might want to have a look at OpenEdge DataServer for Microsoft SQL Server (web.progress.com/en/openedge/dataserver-microsoft.html, documentation.progress.com/output/OpenEdge102b/pdfs/dmsql/dmsql.pdf).
The DataServer provides you with ABL access to a non-Progress database so you can use standard Progress statements, e.g. CREATE to add new records or FOR EACH to retrieve query results.
OpenEdge DataServers are also available for Oracle (using Oracle Call Interface), DB2 and Sybase (using ODBC). The DataServer for MS SQL Server uses ODBC behind the scenes as well. web.progress.com/docs/datasheets/openedge/openedge_dataservers.pdf
You dont need the dataserver, connection with ADODB works fine in ABL, you can even call stored-procedures with the command object, the user you connect with will have to be granted EXEC rigths on the SQL-Server to do that.
I'm not a Progress guru, but I did do some work in it for awhile. AFAIK there is no way to have ABL code connect to a non-Progress database (part of that whole vendor lock-in strategy Progress Corp. leverages).
Your best bet is probably to have the ABL code serialize the records to XML, and use something like ActiveMQ (or even a plain socket or named pipe/FIFO depending on your setup) to send them to a program written in a more capable language to do the SQL insert.
A general question.
I am developing for Sybase SQL Anywhere 10. For backwards comptibility reasons, almost all our Stored procedures are written in Transact-SQL.
Are there any advantages or disadvantages to using T-SQL instead of the Watcom dialect?
Advantages of TSQL:
greater compatibility with Sybase ASE and Microsoft SQL Server
Disadvantages of TSQL:
some statements and functionality are only available in Watcom-SQL procedures. Some examples:
greater control over EXECUTE IMMEDIATE behavior in Watcom-SQL
LOAD TABLE, UNLOAD TABLE, REORGANIZE (among others) are only available in Watcom-SQL
the FOR statement for looping over the results of a query and automatically declaring variables to contain the values is very useful, but not available in TSQL
error reporting is less consistent since TSQL procedures are assumed to handle their own errors, while Watcom-SQL procedures report errors immediately. Watcom-SQL procedures can contain an EXCEPTION clause to handle errors
statements are not delimited by semi-colons, so TSQL procedures are more difficult to parse (and read). Syntax errors can sometimes fail to point to the actual location of the error
no ability to explicitly declare the result set of a procedure
no support for row-level triggers in TSQL
event handlers can only be written using Watcom-SQL
The documentation for SQL Anywhere T-SQL compatibility is available online. There are some database options that change behaviour to more closely match what you would expect from Sybase ASE. In addition, there are some functions that can be used to translate from one syntax to another.
Note that if you want to start adding statements in the Watcom dialect into an existing stored procedure, you will need to change the SP so that it is entirely written in the Watcom dialect. You cannot mix syntaxes in a SP, trigger, or batch.
What KM said - on the other hand, the "Watcom" dialect is much closer to ISO/ANSI-standard SQL, so that dialect is more likely to match to some other products and to appeal to people familiar with SQL standards.
if you ever try to port to SQL Server (or you go for a job on SQL Server), Sybase T-SQL is very close to SQL Server T-SQL. Sybase and MS joined up back in the day, so the core of those languages are very similar.