Avoiding injection attacks in selects

Question

Hi all;

Is there any support in OData for building selects with parameters that we get from users? Both to handle cases like the name "Smith & Jones" and injection attacks?

thanks - dave

---

Who will win The International Collegiate Programming Championships?

Answer 1

Hi,

We don't have that fully yet (it's part of the OData.Contrib project). But we do have building blocks available for you. If the user can only specify a value parameter (so for example $filter=Name eq <parameter>) then this is fully covered by ODataUriUtils class (http://msdn.microsoft.com/en-us/library/microsoft.data.odata.query.odatauriutils_methods(v=vs.103).aspx). The ConvertToUriLiteral takes a primitive value and returns the URI literal (string representation) for it. It will make sure that the value can't "escape" the literal (so no injections possible).

If you allow users to specify for example the entire filter expression then it's pretty much up to you. We don't have a component to verify this for you (yet).

Thanks,

---

Vitek Karas [MSFT]

Answer 2

Hi;

On the additional code being written, I suggest a system where we pass in the select with markets like ":p1", ":p2", etc and parameter values. And it returns the select.

Why?

One case we hit - we passed in a long where it was $top:p1 and it gave us "5L" instead of "5" for the var we were substituting in. Having the entire select you then know that for a $top if it's a byte, short, int, or long - put it in as just the digits.

thanks - dave

---

Who will win The International Collegiate Programming Championships?

Answer 3

I didn't know $top doesn't accept the numerical literals as the rest of the URL does, unfortunate. Sorry about that.

In any case, the code does need to know which portion of the query string is being constructed as the rules are sometimes a tiny bit different. Not only $top obviously doesn't support the same literal format, but the code should also fail if you give it a string value instead of a numerical one.

I don't think the right solution would be for you to provide a string with the query and some "placeholders". I think a better solution would be to have a URI builder API, where you construct the API step by step. And it does the right "Escaping" for you as you go.

Thanks,

---

Vitek Karas [MSFT]

Answer 4

I think either approach would work well.

---

Who will win The International Collegiate Programming Championships?

Answer 5

One thought on this. A common use case for us is we are given the full url, with ${variable} markers in it. So if we had to rebuild the select step by step, we would have to write a parser to parse the select to the rebuild it. That would be a lot of work for everyone using OData under that use case.

On the flip side, it's very easy to replace "${variable}" with ":p1". I think this is why ADO.NET and XmlDocument.SelectNode() both took this approach.

thanks - dave

---

Who will win The International Collegiate Programming Championships?