Isn't defining the fields in "aoColumns" a big security issue?

[Maeldor]

Hi,

I'm new to DataTables and this bundle (and GitHub, in fact; I registered to ask this question!), so apologies if this has been addressed already, but I can't seem to get my head around one thing... Isn't defining the columns in the actual request a big security issue?

I don't know if this is a problem with DataTables itself, or just this bundle, but from following the documentation, it looks like the only way to define the fields to query is for it to be done in the actual public page's code, as detailed here:

    "aoColumns": [
        { "mData": "id" },
        { "mData": "description" },
        { "mData": "customer.firstName" },
        { "mData": "customer.lastName" },
        { "mData": "customer.location.address" }
    ]

To begin with, I dislike having such a thing visible to the public, as it unnecessarily exposes the inner workings of the data. But even more importantly, there's nothing stopping anyone altering the request to get different fields, many of which could contain sensitive data, like passwords (hashed of course!).

Am I really missing something here? I don't understand how such a monumental security flaw like this hasn't already been mentioned, let alone even be possible in the first place, and nothing about is mentioned in the documentation at all.

I would definitely prefer a way to define my fields server-side instead (in my case, in the controller during the creation/retrieval of the datatable itself). Can this be done? I don't want the request to be able to make such a decision! Ever!

Thanks very much,

Maeldor

[gustavopiltcher]

Some time ago I've implemented that and sent a pull request.

#13 (comment)

I also added some more fixes/features but didn't have enough time to create
a documentation yet. But the version on github is pretty usable.

On Friday, July 5, 2013, Maeldor wrote:

Hi,

I'm new to DataTables and this bundle (and GitHub, in fact; I registered
to ask this question!), so apologies if this has been addressed already,
but I can't seem to get my head around one thing... Isn't defining the
columns in the actual request a big security issue?

I don't know if this is a problem with DataTables itself, or just this
bundle, but from following the documentation, it looks like the only way to
define the fields to query is for it to be done in the actual public page's
code, as detailed here:

"aoColumns": [
    { "mData": "id" },
    { "mData": "description" },
    { "mData": "customer.firstName" },
    { "mData": "customer.lastName" },
    { "mData": "customer.location.address" }
]

To begin with, I dislike having such a thing visible to the public, as it
unnecessarily exposes the inner workings of the data. But even more
importantly, there's nothing stopping anyone altering the request to get
different fields, many of which could contain sensitive data, like
passwords (hashed of course!).

Am I really missing something here? I don't understand how such a
monumental security flaw like this hasn't already been mentioned, let alone
even be possible in the first place, and nothing about is mentioned in the
documentation at all.

I would definitely prefer a way to define my fields server-side instead
(in my case, in the controller during the creation/retrieval of the
datatable itself). Can this be done? I don't want the request to be able to
make such a decision! Ever!

Thanks very much,

Maeldor

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17
.

Gustavo Piltcher
Back-end Team Leader
gustavo.piltcher@fixedby.us (msn/gtalk/skype)
+55 (53) 3027.2417
[image: fixedby.us] http://fixedby.us/

This email may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this email in error)
please notify the sender immediately and destroy this e-mail.

[ChadSikorra]

Yeah, it is definitely a security issue depending on what exactly is stored in the table. For some applications and uses it might not be a problem at all. Unfortunately I have been too busy with other things to really dedicate the time needed to implement some much needed features/additions/bugfixes for this bundle.

Ideally I would like some exclusion policy annotation feature much like you can do with the JMSSerializerBundle. That way you could easily define which columns are allowed and which aren't through some simple annotation. For the time being I would suggest using @gustavopiltcher branch until it's implemented. I also suppose you could do a check yourself in the request array to look for only certain allowed columns prior to calling the service like so $datatable = $this->get('lankit_datatables')->getDatatable('AcmeDemoBundle:Customer');. That might be a little messy, but it should be doable anyway.

[Maeldor]

Thanks very much for the replies!

I noticed your pull request, actually, @gustavopiltcher. I didn't realise it could potentially solve the issue, though. I shall take a look into it! Thank you.

@ChadSikorra, I understand you're busy, no worries. I was considering that I would have to check the request array first, but yeah, that's a bit messy. I do very much look forward to your changes you mentioned, though!

I'll take a look into both possibilities! If I do use @gustavopiltcher's branch, is there anything I should know to ensure it's secure and won't use the request array?

Thanks!

[gustavopiltcher]

Yes, you can try to inject anything in the frontend, like
"user.password" nothing will be returned, only the exactly fields from your
controller. You can see some samples in the documentation of that branch:
https://github.com/gustavopiltcher/DatatablesBundle/blob/00a2162f7ad5008ac972591e77b561e8969541f0/Resources/doc/index.md

On Friday, July 5, 2013, Maeldor wrote:

Thanks very much for the replies!

I noticed your pull request, actually, @gustavopiltcherhttps://github.com/gustavopiltcher.
I didn't realise it could potentially solve the issue, though. I shall take
a look into it! Thank you.

@ChadSikorra https://github.com/ChadSikorra, I understand you're busy,
no worries. I was considering that I would have to check the request array
first, but yeah, that's a bit messy. I do very much look forward to your
changeshttps://github.com//pull/13#issuecomment-14801948you mentioned, though!

I'll take a look into both possibilities! If I do use @gustavopiltcherhttps://github.com/gustavopiltcher's
branch, is there anything I should know to ensure it's secure and _won't_use the request array?

Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-20546181
.

Gustavo Piltcher
Back-end Team Leader
gustavo.piltcher@fixedby.us (msn/gtalk/skype)
+55 (53) 3027.2417
[image: fixedby.us] http://fixedby.us/

This email may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this email in error)
please notify the sender immediately and destroy this e-mail.

[Maeldor]

Ah, excellent, thanks very much! This is exactly what I was looking for!

[Maeldor]

Seems to be working great, thanks!

However, I have noticed (even with the LanKit master) that it's not showing results that have no related results. For example, if I'm showing a list of all users and there's a column that shows the groups they're in, it doesn't display the users that have no groups. Is this to be expected? I need it to still show them, but just have an empty field in that case.

I can confirm it immediately shows the users without groups if I exclude the groups column from the request.

It's late and I need to go to bed, so I couldn't look into it further, but I thought I'd ask in case you're aware of why it's doing this. I'll try and figure it out tomorrow if you're not sure.

Thanks!

[gustavopiltcher]

@Maeldor , you can use something like: $dataTable->setJoinType('groups', Datatable::JOIN_LEFT); to create a left join on user.groups.
In addition to this, take a look on Column post-filtering section from the documentation of my branch, it allows you to add some additional logic in the back-end for any returned data/array.