Where to find PL/SQL injection checking library/code - plsql

I would like to know whether anyone knows about a library or code that will accept a PL/SQL string and thow error if there is any PL/SQL injection. Most of the open source projects in the internet are created in PHP.

You need to use parameters, for example
UPDATE mytable SET field=:param WHERE id=:id
And then assign :param and :id to be the value that you get from the untrusted source (form value, url params, cookie, ...)
This also improves performance, and you don't need to parse anything to determine if it's injection or not. (Such approaches might have subtle bugs that you don't see, but the attaker will use. I mean you cannot verify that every possible attack, including those you haven't thought of yet, will be stopped by an injection-detection logic.)

Assuming you have a very good reason to use both dynamic SQL and to embed strings in your statements rather than use bind variables, Oracle has a built-in library for this purpose. It's called dbms_assert.
See http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_assert.htm for full details on this package.

Related

SQLite - if I block " from strings, can I be SQL injected?

I'm using this code (python using sqlite3) to add data to the table:
''' INSERT INTO TABLE (USERNAME) VALUES ("''' + data + '''")'''
If I block ", then (to the best of my knowledge) it should be impossible to exit the string, subsequently making it impossible to SQL inject.
My questions are these:
Does this stop users from being able to inject SQL?
If no, should I add more to the blacklist or create a whitelist?
All help is greatly appreciated.
If you sterilize data before letting it hit the insert statement, making sure that single quotes do not appear anywhere, then in theory SQL injection is not possible. Whatever data gets injected should just be treated a string literal, rendering any injected SQL commands ineffective. However, there may still be ways for an attacker to work around this.
Your best best here would be to just rely on using prepared statements to avoid SQL injection. Attackers keep getting smarter, and there might still be a way to inject your current insert statement from some other means.

Is there a way to validate the syntax of a Salesforce.com's SOQL query without executing it?

I'm writing an API that converts actions performed by a non-technical user into Salesforce.com SOQL 'SELECT', 'UPSERT', and 'DELETE' statements. Is there any resource, library, etc. out there that could validate the syntax of the generated SOQL? I'm the only one at my company with any experience with SOQL, so I'd love to place it into a set of automated tests so that other developers enhancing (or fixing) the SOQL generation algorithm know if it's still functioning properly.
I know one solution here is to just make these integration tests. However, I'd rather avoid that for three reasons:
I'd need to maintain another Salesforce.com account just for tests so we don't go over our API request cap.
We'll end up chasing false positives whenever there are connectivity issues with Salesforce.com.
Those other developers without experience will potentially need to figure out how to clean up the test Salesforce.com instance after DML operation test failures (which really means I'll need to clean up the instance whenever this occurs).
You might solve your problem by using the SoqlBuilder library. It generates SOQL for you and is capable of producing SOQL statements that would be quite error prone to create manually. The syntax is straight forward and I've used it extensively with very few issues.
I found another way to do this.
Salesforce.com posted their SOQL notation in Backus-Noir Form (BNF) here:
http://www.salesforce.com/us/developer/docs/api90/Content/sforce_api_calls_soql_bnf_notation.htm
This means you can use a BNF-aware language recognition tool to parse the SOQL. One of the most common tools, ANTLR, does this and is free. Following the ANTLR example, pass the SOQL grammar into its grammar compiler to get a Lexer and a Parser in your desired language (C#, Java, Python, etc.). Then you can pass the actual SOQL statements you want to validate into the Lexer, and then your Lexer tokens into your Parser, to break apart the SOQL statements. If your Lexer or Parser fails, you have invalid SOQL.
I can't think of a way to do this from outside of Salesforce (and even in Apex I've only got one idea right now that may not work), but I can think of two suggestions that may be of help:
Validate queries by running them, but do them in batches using a custom web service. i.e. write a web service in Apex that can accept up to 100 query strings at once, have it run them and return the results. This would drastically reduce the number of API calls but of course it won't work if you're expecting a trial-and-error type setup in the UI.
Use the metadata API to pull down information on all objects and their fields, and use those to validate that at least the fields in the query are correct. Validating other query syntax should be relatively straight forward, though conditionals may get a little tricky.
You can make use of the salesforce develop nuget packages that leverages SOAP API

Accessing CoreData tables from fmdb

I'm using CoreData in my application for DML statements and everything is fine with it.
However I don't want use NSFetchedResultsController for simple queries like getting count of rows, etc.
I've decided to use fmdb, but don't know actual table names to write sql. Entity and table names don't match.
I've even looked inside .sqllite file with TextEdit but no hope :)
FMResultSet *rs = [db getSchema] doesn't return any rows
Maybe there's a better solution to my problem?
Thanks in advance
Core Data prefixes all its SQL names with Z_. Use the SQL command line tools to check out the your persistent store file to see what names it uses.
However, this is a very complicated and fragile solution. The Core Data schema is undocumented and changes without warning because Core Data does not support direct SQL access. You are likely to make error access the store file directly and your solution may break at random when the API is next updated.
The Core Data API provides the functionality you are seeking. IJust use a fetch request that fetches on a specific value using an NSExpressionDescription to perform a function. This allows you to get information like counts, minimums, maximums etc. You can create and use such fetches independent of a NSFetchedResultsController.
The Core Data API is very feature rich. If you find yourself looking outside the API for a data solution, chances are you've missed something in the API.

Is there a utility for finding SQL statements in multiple files and listing any referenced tables and stored procedures

I'm currently looking at a terrible legacy ColdFusion app written with very few stored procedures and lots of nasty inline SQL statements (it has a similarly bad database too).
Does anyone know of any app which could be used to search the files of the app picking out any SQL statements and listing the tables/stored procedures which are referenced?
Dreamweaver will allow you to search the code of the entire site. If the site is setup properly including the RDS password and provide a data source it can tell you a lot of information. I've only set it up once so I can't remember exactly what information it gives you, I think maybe just the DB structure. Application window > databases. Even if it isn't set up properly just searching for "cfquery" will quickly find all your queries.
You could also write a CF script using CFDirectory/CFFile to loop the .cfm files and parse everything between cfquery and /cfquery tags.
CFBuilder may have some features like that but I'm not to familiar with it yet.
edit I've heard that CFBuilder can't natively find all your cfqueries that don't have cfqueryparam but you can use CF to extend CFB to do so. I imagine you could find/write something for CFB to help you with your problem.
another edit
I know it isn't indexing the contents of the query, but you can use regex to search using the editor as well. searching for <cfquery.+(select|insert|update|delete) checking the regex box should find the queries that aren't using cfstoredProc (be sure to uncheck the match case option if there is one). I know Dreamweaver and Eclipse can both search for Regex.
HTH
As mentioned above I would try a grep with a regex looking for
"<cfquery*" "</cfquery>" and "<cfstoredproc*" "</cfstoredproc>"
In addition if you have tests that have good code coverage or even just feel like the app is fully exercised in production you could try turning on "Log Database Calls" in Admin - > Datasources or maybe even at the JDBC driver level, just monitor performance to make sure it does not slow the site down unacceptably.
In short: no. You'd have to do alot of tricky parsing to make sure you get all the SQL. And because you can glob SQL together from lots of strings, you'll almost always miss some of it.
The best you're likely to do will be a case insensitive grep for "SELECT|INSERT|UPDATE|DELETE" and then manually pulling out the table names.
Depending on how the code is structured, you might be able to get the table names by regexing the SQL from clause. But that's not foolproof. Alot of people use string concatenation to build SQL statements. This is bad because it can introduce SQL injection attacks, and it also make this particular problem harder.

Package for prevention of sql injection

Is there any pl/sql package which is already written to handle all the scenearios which prevents SQL Injection.Please let me know if any one aware such package.
Thanks for your help
Prepared Statements
just use prepared statements in PL/SQL. That will protect against sql injections
Thanks for reply , I am looking for a package that validates user inputs. Like checks for only alpha numeric and special symbols etc etc It would be great helpful if package exits to check all scenarios –
It sounds more like you want an ORM for applications that use the database more than a PostgreSQL package. Or at least encapsulate your code in a function to provide parameterization.
Think about it this way. SQL injection works by turning invalid input into malicious (but valid) SQL. How would the database be able to determine anything else as far as whether or not it's valid SQL? And if it could tell otherwise in all cases, why wouldn't it just do that by default instead of requiring you to use a certain package?

Resources