0

I’m currently using DataTables.js with server-site data source written on PHP.

The server-side script gives out the data exactly as required by datatables:

{“iTotalDisplayRecords”:”777”,”sEcho”:0,”aaData”:[[row1],[row2],[row3]]}

Now I would like to add an additional security layer with encrypting the response from the server and decrypting it after it is received by datatables.

I need this as I noticed some of the clients work through HTTPS proxy and the content of some rows get mistakenly blocked.

I’m using this solution for server-side PHP script to give out encrypted content using openssl_encrypt.

Then at client side I have:

function datatable_init (source) {
  $.getJSON(source, function(data) {
    decryptedContent = JSON.parse(CryptoJSAesDecrypt(“password”, data));
    oTable = $(‘dtable’).dataTable({
      “bProccesing”: false,
      “bServerSide: true,
      //“sAjaxSource”: source,
      “data”: decryptedContent
      ...
    });

I had to replace ”sAjaxSource” to ”data” as it is different datasource type now which requires different type of datatable JSON format:

{data:[[row1],[row2],[row3]}

and I can’t to pass iTotalDisplayRecords anymore.

Is there a way I can keep feeding server-side format of JSON to datatable but feed it as a local JS object/array?

P.S. Another idea I had is to encrypt/decrypt each individual row of the table but that’s probably going to be more complicated and slower

user164863
  • 580
  • 1
  • 12
  • 29
  • 1
    Encrypting anything to be decrypted client side by a browser is entirely pointless as the client can't be trusted – eddiewould Jun 23 '19 at 22:06
  • @eddiewould But I will go by the proxy at least. Otherwise, is a browser extension will be better security-wise? – user164863 Jun 23 '19 at 22:10
  • 1
    1) Ensure your API is served only over HTTPS to prevent eavesdropping 2) Ensure your have appropriate authentication & authorization mechanisms in place so that you know who accessing your API and that they have permission to do so. – eddiewould Jun 24 '19 at 00:00
  • @eddiewould Yes, I have that. Would a session_id be a good password for JS encryption in this case? – user164863 Jun 24 '19 at 00:23
  • If your traffic is already encrypted w/ HTTPS and you've authenticated the user/agent and checked they're authorized to access the resource then adding further encryption is adding zero benefit. – eddiewould Jun 24 '19 at 00:33
  • If you're sending stuff to the browser that the user might not be authorized to view, then you should stop doing *that* rather than trying to obfuscate things. – eddiewould Jun 24 '19 at 00:35
  • @eddiewould it might be a matter for separate discussion, but lets say I go to internet cafe with a https filtering proxy. That proxy blocks everything with "ice cream" word. So even if a user authorized with login and password over https it still breaks the datatables if any cell of it contains that word, because the proxy decrypts all the traffic and then filter it – user164863 Jun 24 '19 at 09:59
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/195458/discussion-between-eddiewould-and-user164863). – eddiewould Jun 24 '19 at 11:50
  • 1
    The third party proxy _can't_ decript the traffic (unless something has gone wrong) - HTTPS is end-to-end encryption - that's the whole point of it. – eddiewould Jun 24 '19 at 11:57

1 Answers1

1

The ajax.dataSrc option seems to be helpful, because it provides the possibility to modify the data received via ajax and thus allows you to define a function which takes care of decrypting the received data again. Especially the last example given on the reference page looks promising in my opinion.

Javan
  • 189
  • 1
  • 7