I'm setting up a small app using AWS-amplify.
Due to the the queries I needed to perform I needed to use a SQL database.
I've therefore made an Aurora database and connected in to my amplify graphql API via the "amplify api add-graphql-datasource" command.
This generates the cloudformation templates for the resolvers to perform basic CRUD operations on the Aurora DB.
I wanted to perform some dynamic queries like:
"SELECT * FROM Question Where type = {ctx.input.type}"
How do I protect the gql input from sql-injection attacks?
Does VTL have a custom function which will escape these inputs? - or alternatively throw an error if a special character exists?
I know i could setup either write all of this logic in the vtl resolver or create a pipeline resolver that does all of this in a node lambda but just wondering if there is a simpler solution.
Related
There is a lot of image files being returned by the DB(Either PostgreSQL RDS/Amazon Aurora). We need to sign the URL. Currently, a user defined function or a view returns the records.
I am looking for a way to sign the S3 URL directly in SQL as a user defined function. Unfortunately, there does not seem to be a way other than using Python language inside a user defined function and python is not supported as a procedural language in PostgreSQL/Aurora.
Does someone know of a way we can sign the URL directly as part of a SQL Query in PostgreSQL RDS/Amazon Aurora?
Database is not the place to perform such operation.
You should consider either putting a signed URL into the database already or to rethink your application if it shouldn't be rearchitected.
Im working on postgraphile server. the stack is: nodejs, expressjs, postgraphile and knex.
My auto-generated graphiql exposes queries to tables it doesn't need to - knex_migrations.
following this doc: https://medium.com/make-it-heady/graphql-omit-table-from-generating-under-graphiql-postgres-smart-comments-6d3b6abec37
in the pgAdmin, I added in the properties of the knex_migrations table the followings:
#name knex_migrations
#omit create,update,delete
This is the documentation.
still when running the server and opening graphiql, I see queries for the migrations table.
what am I missing
If you want to completely omit the table completely from your graphql schema using a smart comment, you simply need to use the #omit tag without any following actions. Using #omit create,update,delete only removes the autogenerated mutations -but does not remove read operations (usage in queries).
See docs for #omit for all available options.
I am using prisma and yoga graphql servers with a postgres DB.
I want to implement authorization for my graphql queries. I saw solutions like graphql-shield that solve column level security nicely - meaning I can define a permission and according to it block or allow a specific table or column of data (on in graphql terms, block a whole entity or a specific field).
The part I am stuck on is row level security - filtering rows by the data they contain - say I want to allow a logged in user to view only the data that is related to him, so depending on the value in a user_id column I would allow or block access to that row (the logged in user is one example, but there are other usecases in this genre).
This type of security requires running a query to check which rows the current user has access to and I can't find a way (that is not horrible) to implement this with prisma.
If I was working without prisma, I would implement this in the level of each resolver but since I am forwarding my queries to prisma I do not control the internal resolvers on a nested query.
But I do want to work with prisma, so one idea we had was handling this in the DB level using postgres policy. This could work as follows:
Every query we run will be surrounded with “begin transaction” and “commit transaction”
Before the query I want to run “set local context.user_id to 5"
Then I want to run the query (and the policy will filter results according to the current_setting(‘context.user_id’))
For this to work I would need prisma to allow me to either add pre/post queries to each query that runs or let me set a context for the db.
But these options are not available in prisma.
Any ideas?
You can use prisma-client instead of prisma-binding.
With prisma-binding, you define the top level resolver, then delegates to prisma for all the nesting.
On the other hand, prisma-client only returns scalar values of a type, and you need to define the resolvers for the relations. Which means you have complete control on what you return, even for nested queries. (See the documentation for an example)
I would suggest you use prisma-client to apply your security filters on the fields.
With the approach you're looking to take, I'd definitely recommend a look at Graphile. It approaches row-level security essentially the same way that you're thinking of. Unfortunately, it seems like Prisma doesn't help you move away from writing traditional REST-style controller methods in this regard.
What should an Incident Handler do (or) follow when an SQL injection attack is reported?
Initial Response
Analysis
Action
Aiming to make a Procedure guide to follow for myself and my team.
Brief or detail, anything would help.
Not a full process, but it should get you started:
Initial Response
Verify that the reported vulnerability is legitimate, preferably in a production-safe manner
See the OWASP SQL Injection Testing guide for more information on how to do this
Analysis
Determine the cause of the SQL Injection
This is probably a location where user input is directly concatenated into a SQL query
Action
The best defense against SQL Injection is to utilize parameterized/prepared statements instead of direct string concatenation when building a query based on user input.
These statements provide a clear divide between data and syntax, so that user input is never treated as SQL syntax but instead treated as data
How you do this will depend on the language and framework used in your application
See the OWASP SQL Injection Prevention Cheat Sheet for more information on preventing SQL injection
I'm developing an Azure application using this stack:
(Client) Angular/Breeze
(Server) Web API/Breeze Server/Entity Framework/SQL Server
With every request I want to ensure that the user actually has the authorization to execute that action using server-side code. My question is how to best implement this within the Breeze/Web API context.
Is the best strategy to:
Modify the Web API Controller and try to analyze the contents of the
Breeze request before passing it further down the chain?
Modify the EFContextProvider and add an authorization test to
every method exposed?
Move the security all into the database layer and make sure that a User GUID and Tenant GUID are required parameters for every query and only return relevant data?
Some other solution, or some combination of the above?
If you are using Sql Azure then one option is to use Azure Federation to do exactly that.
In a very simplistic term if you have TenantId in your table which stores data from multiple tenants then before you execute a query like SELECT Col1 FROM Table1, you execute USE FEDERATION... statement to restrict the query results to a particular TenantId only, and you don't need to add WHERE TenantId=#TenantId to your query,
USE FEDERATION example: http://msdn.microsoft.com/en-us/library/windowsazure/hh597471.aspx
Note that use of Sql Azure Federation comes with lots of strings attached when it comes to Building a DB schema one of the best blog I have found about it is http://blogs.msdn.com/b/cbiyikoglu/archive/2011/04/16/schema-constraints-to-consider-with-federations-in-sql-azure.aspx.