I'm trying to encrypt query parameters in an Angular 5/6 project. We have some sensitive data in the URL which we might need to encrypt or hash so an outside user won't know.
Is there a way to do that or worth doing? For example, would that be really safe, or maybe have a big impact on performance?
I've seen some routing configured as /edit/:id/:name, but I'm confused as to whether it's really safe to expose the ID or other parameters in the URL.
Like #jonrsharpe suggest, we can use eventEmiiter or subject through service to pass data as an object in between component so no need to work on hash query parameter in routing.
Related
If I have a route in Express with route parameters which are used to query my database, do I need to sanitize this parameter before using it?
What you do and don't need to sanitize is entirely dependent upon what you're doing with it.
The content in a route parameter comes entirely from the user so it can be anything that is allowed in a URL and matches your route parameter. That means there are possibilities that something harmful could be injected within that. But, again whether harm is actually possible or not, depends on the exact code you're using. If you were injecting this user content into a SQL statement, then there are all sorts of bad things it could do. If you were just using it as a programmable query argument in a specific database API, there may be no harm.
So, there is no general purpose answer that applies to all possible uses of the data. It depends on the exact code you're using it in.
If in doubt, sanitize and validate the user input before using it.
I'm new in API developement and I wanted to know what is the best choice to create pagination :
GET resquest with query params (sort, limit, etc)
POST request with params in the body (sort, limit, etc)
I was more on the GET but my coworkers thinks POST is a better choice, so I just wanted your opinion.
GET would be the usual choice.
General purpose components will understand that the semantics of GET are safe, which means they are also idempotent. If a GET request receives no response, you can automatically retry it without any concerns about loss of property.
Furthermore, if all of the information you need to identify the resource is included in the URI, then you can bookmark the URI, or paste it into an email, or link to it in a document, and it will all "just work".
Also, using GET -- with all of the relevant details encoded into the resource identifier -- means that the response can be cached and re-used. The constraints on caching POST requests mean that you can't capture the information in the request body.
At some point in the future, HTTPWG will register a new HTTP method to cover the safe method with a body case, which may change some of the answers.
In the meantime, it is okay to use GET.
GET is the recommended way to do this, because the answer can be cached and the goal is reading not writing. You can use the query string or range headers for pagination. The exact solution depends on your needs. There are a few standard query languages for this, like OData, but they are overkill for a simple API. Building a custom solution on top of URI templates might be a better choice, or there are non-standard query languages too like RQL, which can be completely or partially implemented in your solution.
I am developing an identity server 4 dotnet core application so this is as much as a dotnet question than and IDS4 question. One example of state I need to maintain between pages (login, signup etc...) is the returnUrl. The application I'm migrating from used to store it in a session variable but, as I understand, unless I run a persistent session strategy, this won't scale well.
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach? I'll be needing other fields to be passed around as well so I'm wondering whether this is a secure and logical way to do it.
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach?
Yes, how you choose to pass it around is up to you, I choose this same approach. You could use TempData, Sessions or even localStorage as an alternative. I think having it in the models (view models) is a good approach because you are explicitly specifying where you want the return url to exist, otherwise it might persist in context that you wouldn't want.
Now the security question because obviously you might be able to see the return url in the browser address field.
As part of Identity Server 4 setup you specify which return url's you are allowed to redirect back to, so I don't think there is any harm in having the users see the redirect url.
Something to consider is what if the user would share the url to someone else in the middle of the authentication process, would they be able to resume from that part of the process that the initial user has stopped? is this something you want in your app?
If you mean reliably instead of securely, write tests which will provide you with confidence that your code works.
We are creating a RESTful API (PHP on apache server) which will communicate with an Android application. Im new for this so excuse me if my question is dumb.
I want to ask for data from the api so I need to use GET method in the request taking into account the semantics. I have to send some additional data to specify what data am I requesting. In GET requests, I cannot send form data fields so how should I attach the data?
Using POST (but this is not semantic)
request header: POST http://example.com/api/v1/serials
request data: date_from=2013.01.01&date_to=2014.01.01&userid=112&is_in=0&starts_with=afx00
using GET and adding url params (I don't know if is this a good practice in a REST API)
request header: GET http://example.com/api/v1/serials?date_from=2013.01.01&date_to=2014.01.01&userid=112&is_in=0&starts_with=afx00
or making well formed URIs with no url params in GET (not sure about this as well.)
request header: GET http://example.com/api/v1/serials/date_from/2013.01.01/date_to/2014.01.01/userid/112/is_in/0/starts_with/afx00
Which one fits the best in the RESTful API architecture? Which should I use and why? Or maybe are there any other options for what I want?
Without question using URL parameters is best. It allows consumers to query for serials using their choice of filters. Your API should support returning results based on UserId alone, or a date range, or both. Or other combinations of inputs that make sense.
Embedding the key/value pairs of the filter in the resource path is an anti-pattern. It's difficult to understand what each path element means, and you would need to contort your routing engine to accommodate additional filter criteria. It also provides no flexibility in terms of choosing what filter criteria to use - you would in fact need to construct multiple resources paths for each combination of filters. And there is the management of ordering each pair (with URL params, ordering doesn't matter). Probably more reasons to avoid this, but those are the first that spring to mind.
Bot GET methods can be used. It is your choise. But I'll prefer using url params. It is easier.
What is the best way to avoid SOQL Injection when querying salesforce through the APIs?
The two main APIs I am interested in are the SOAP and REST APIs.
My current methods are to never use any input from the user (which is impractical if they are searching for a Company Name) or encoding certain characters within the string.
However I saw that there was parameterisation within the APEX, so i was wondering if there was a similar way of doing it through the APIs.
I think all you really need to do is to make sure that the input, in this case the company name, is escaped properly. I am not aware of a parameterized way of building a query object for either of the API's.
However, if you needed to you could expose a custom web service method from within Salesforce so that you can pass the value in. Then from within the Salesforce Apex Code language you can parameterize the value using a syntax similar to below:
public Account[] queryCompany(string companyName) {
return [SELECT Id FROM Account WHERE Name = :companyName];
}
Philosophical rant
What are you after really :)
If your application should work same way accessed from different sources (Salesforce UI, PHP connector, some mobile applications) then it probably makes most sense to think about Apex like some stored procedures that will be reused. This means you'd be passing safe parameters to them.
If you plan to hand-craft queries & not rely on Apex too hard - maybe what you need is something like database.com or other cloud-based DB solutions?
Actual answer
I'm not aware of an out of the box way to pass separately the query command and separately the params to it (like bind variables/prepared statements) through APIs. Both REST and SOAP API give you what's essentially Database.query() within Apex. Sure, there are some differences like retrieve() command or queryMore() but that's the baseline.
What you could do is to either expose some commonly used searches with methods similar to what John proposed (bonus points for extra performance - they're precompiled) or build something generic?
List<sObject> runQuery(String query, List<List<String>> params){...}
If the runQuery will contain bind variables like params[0] it should work. Looks crazy and I didn't test it though ;) I'd say that bind variables are the best method. Alternative would be to escape user's input but SQL and XSS injections can become amazingly creative. Check Examples of XSS that I can use to test my page input? for a start (yes, I'm aware you asked about SOQL only).
As for actual SOQL injection: http://wiki.developerforce.com/page/Secure_Coding_SQL_Injection. Since "worst that can happen" is that users will search for more than they were supposed to (no way to convert SELECT into INSERT) escaping should be safe-ish...