We have a .Net 4.0 project that is being scanned by Veracode in order to acquire security certification.
During static scan the following vulnerability has been found:
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE ID 89) See details at https://cwe.mitre.org/data/definitions/89.html
The report details file & line number that seems to refer to Dapper:
OurOwnDll.dll dev/.../dapper net40/sqlmapper.cs 1138
App_Browsers.dll dev/.../sqlmapperasync.cs 126
OurOwnDll is using Dapper.
App_Browsers.dll I´m not aware where it is coming from, but seems to be related to the site project, and seems to be related to the browsers capabilities detection of asp.net.
I would like to know if there is any way to prevent this vulnerability.
I am not familiar with VeraCode, however as pointed out by #Kristen Waite Jukowski, your issue may be due to the fact that some of your queries are not parameterised, in which case they are correctly being identified as vulnerable to SQL injection.
Alternatively, a similar question (relating to the same issue but with OrmLite) may shed some light on this. Similar to OrmLite, as dapper provides the facility to write raw SQL queries that could be composed with inputs that are not parameterised (for example by string concatenation), using it may be deemed a vulnerability, even if every query in your particular project is currently fully parameterised. The answer to that question (which may not be viable in your case) was to replace the existing ORM with Entity Framework:
During a code-readout with VeraCode the suggested proper remediation
was to replace ServiceStack ORM with EntityFramework 6.1.
From the comments in that question:
The difference is in EF, the executing context implements IDbCommand
but the CreateDataAdapter and other api's that can allow dynamic sql
have been implemented to throw exceptions. There are no code paths in
EF that allow dynamic sql without first going through a filtering
mechanism similar to OWASP.
Related
I am looking for the XSD to use to support a Decoding action in Logic Apps for the X12 830 00200. This was approved by ANSI in 1986 (pre-ASC), but is still widely used by Ford. I understand the same XSD would be used in a BizTalk Server solution. Does anyone have one to share?
I have tried the download item MicrosoftEdiXSDTemplates.zip as part of Microsoft Azure BizTalk Services SDK Setup:
https://www.microsoft.com/en-us/download/details.aspx?id=39087
However that only goes back to 00204, which I tried unsuccessfully adapting.
I would rather not do this as a Flat File Decode, as I want all X12 830 processing in my Logic Apps solution to have a consistent, Agreement-based configuration.
I have sample EDI, drawn from the real-world.
I will be using Ford's specs for the v002001FORD 830O to validate any schema I obtain or create: https://www.gsec.ford.com/GEC/edispecs/830.pdf
** UPDATE **
Thanks all for the help. It ends up that on the MS side, the Kusto log analytics trace of my run-time activity shows explicit duplicate schema references in my Agreement, while my run-time exception from Logic Apps does not clearly indicate a duplicate schema issue is present: 'The message has an unknown document type and did not resolve to any of the existing schemas configured in the agreement.' So, there was nothing wrong with my schema. I just had to tweak my Agreement configuration. I am reporting this to MS and hope the schema validation in the Agreement and/or the exception reporting will be improved.
To me a broader issue is that the X12 schema provided are ASC-issued ones: 02000, 03000, 04000, etc.. The same ones prevented from being shared on Git due to copyright issues. The reason I believe I am running into older, ANSI-issued specs still in used despite their age by Ford, Toyota, etc. is that the same copyright issues tends continued usage by OEMs of these specs despite their age. For that reason, it would be a big help to the community if MS provided the XSDs for the ANSI-issued X12 specs as is done for the ASC-issued ones. For each ASC-issued spec, such as 04000, there are many documents: 830, 856, etc. This multiplies out to scores if not hundreds of handcrafted XSDs one may need to produce (as is our case) to implements broad X12 support in Logic Apps.
The process with outlier EDI Schemas is to find the closest one and modify it to support the version you need.
What do you mean by 'unsuccessfully adapting'? This is not an uncommon thing.
Since the spec is so old, one thing I would very much consider is bumping the interchanges up to a 'current' :) version, even just 00204. I'm not sure the specific value 00200 will work with BizTalk EDI.
You would use a custom Pipeline Component for the incoming and should be able to use the EDI.Override properties on outbound.
I am currently working on a project where we need to test the database packages and functions.
We need to provide the input parameters to the database package and test the packages returns the expected value, also we want to test the response time of the request.
Please advice, if there is any tool available to perform this or we can write our test cases in Junit or some other framework.
Which one will be best approach?
I've used a more native approach when I had to do DWH testing. I've arranged the Test framework around the Dev data integration framework that was already in place. So i had a lot of reusable jobs, configurations and code. But using OOP like you suggest
write our test cases in Junit
is a way to go too. But keep in mind that very often the DWH design is very complex (with a lot of aspects to consider) and interacting with the Persistence layer is not always the best candidate for testing strategy. A more DB oriented solution (like tSQLt) offers a significant performance.
Those resources helped me a lot:
dwh_testing
data-warehouse-testing
what-is-a-data-warehouse-and-how-do-i-test-it
My framework Acolyte provides a JDBC driver & tools, designed for such purposes (mock up, testing, ...): http://tour.acolyte.eu.org
It's used already in some open source projects (Anorm, Youtube Vitess, ...), either in vanilla Java, or using its Scala DSL.
handler = handleStatement.withQueryDetection(...).
withQueryHandler(/* which result for which query */).
withUpdateHandler(/* which result for which update */).
// Register prepared handler with expected ID 'my-unique-id'
acolyte.Driver.register("my-unique-id", handler);
// then ...
Connection con = DriverManager.getConnection(jdbcUrl);
// ... Connection |con| is managed through |handler|
We have our application developed and tested with sql server 2008r2 using ASP.NET on windows server. Now we have a requirement to move the database from windows to oracle on red hat linux.
We haven't yet setup the infrastructure to test the same. I would like to know in the meantime if anyone has successfully done this kind of thing. Pointers to any resources will be a great advantage.
Is changing the connection string the only thing that needs to be done or are there any specific configuration in Linux to allow this?
I will verify this once I get the environment ready, but as a headstart if anyone has any similar experience, do share.
Thanks in advance.
P.S: For migration of table structure, storedprocedures etc to oracle we will be using the Sql Developer tool.
I would like to answer my question,because, migration to oracle is not that straight forward, but there are some tips that may help anyone migrate to oracle on windows or linux with less headache.
The first thing the Sql developer tool does a good job of migrating sqlserver schema and data to oracle including storedprocedures, constraints, triggers etc.
It also does a good job of datatype mapping and provides option to remap datatype if required.
Some caveats and precautions.
Oracle has a limitation on the length of stored procedure names of about 30 characters. This is the area you need to resort to some manual renaming as when migration SP's or identifiers whose name is greater than 30 characters may get truncated.
The other common issue that you may face is respect to date insertion and formatting. You can use the following snippet to avoid the headache. The common error will be "Not a valid month."
OracleConnection conn = new OracleConnection(oradb); // C#
conn.Open();
OracleGlobalization session = conn.GetSessionInfo();
session.DateFormat = "DD.MM.RR"; // change the format as required here
conn.SetSessionInfo(session);
The most annoying error would be well character to numeric conversion when inserting or updating data or related error.
The issue here is when you add parameters to command object for sql provider, the binding happens by name, but forOracle.DataAccess the default binding is by position. Here's the post that saved me lot of headache.
ODP .NET Parameter problem with uint datatype
What you can do is set the command.BindByName = true;
When migrating SP's that returns data, oracle creates an out parameter ref cursor. This needs to be taken care of while constructing command parameters.
For e.g.
OracleParameter refp = new Oracle.DataAccess.Client.OracleParameter("cv_1", OracleDbType.RefCursor, ParameterDirection.InputOutput);
command.Parameters.Add(refp);
Also the sqlserver requires parameters to SP be prefixed with "#" and oracle doesn't. This can be easily taken care of in your data layer.
Also since there is no bit datatype in Oracle, number(1) works fine. You may need to convert your bool to numeric, if required.
Hope this helps someone avoid a migration headaches. I will post more issues if I encounter.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
Am trying to run a C# application which fetches data from PostgreSQL database(8.4) and am using the PostgreSQL OLE DB Provider
This is my connection string
string connString =
#"Provider=PostgreSQL OLE DB
Provider;Data
Source=localhost;location=;User
ID=;password=;timeout=1000";
The error am getting is
The 'PostgreSQL OLE DB Provider'
provider is not registered on the
local machine
Can anyone point out me where should I correct so as to get the connect to the database. By the way am using PGOLEDBLib.
I have seen a few different "pgoledb" libraries. None appear to actually be named "pgoledblib", so this info may or may not apply to you.
The most recently active PGOLEDB has documented their connection string attributes here; it appears they use a different Provider value -- "PGNP.1".
Another provider, which seems to have been languishing since 2006, has connection strings here; these are in line with the earlier suggestions from OrbMan.
Of course, you may find that paying nothing for such a provider leads to paying much in installation, configuration, and utilization headaches. Towards easing such headaches, I offer a link to my employer's options supporting ODBC, JDBC, and ADO.NET clients on many platforms.
Any particular reason you're using the OLE DB provider? I believe the general idea is that you get better performance, and I think also functionality, if you use a native .net provider - e.g. http://npgsql.projects.postgresql.org/
Try using "PostgreSQL" or "PostgreSQL.1" for the Provider attribute.. If that does not work, you will probably need to re-install the driver.
I found the solution.
Step 1: Down load & install
https://www.pgoledb.com/index.php/component/filecabinet/?task=download&cid[0]=15
Step 2: Restart PC.
Step 3: Set the connection string as below
Provider=PGNP.1;Data Source=localhost;Persist Security Info=True;Initial Catalog=myDatabase;User ID=yyy;password=xxx
It should work as your expected