Can you prevent HTML from being modified?
Enterprise system HTML can be modified ("hacked"), allowing a user to see data they shouldn't see, by inspecting the page.
I'm no web programmer but generally familiar with HTML. I was really surprised that the HTML could be modified so easily.
The HTML is generated from Oracle Designer, a really old tool that is outdated but we're still using it.
Isn't there some way to mask the code? or make it unchangeable? We've also had issues in the past where SQL code / values are exposed and were able to be changed. That too surprised me. That was fixed with some back-end programming (the HTML could still be modified).
In the screen shot, the ID # can be changed and so the user can see another user's info, by either guessing another's ID or sleuthing to find someone specific's ID.
Inspect-HTML-and-change.png
I'm no web programmer but generally familiar with HTML. I was really surprised that the HTML could be modified so easily.
The HTML is generated from Oracle Designer, a really old tool that is outdated but we're still using it.
Isn't there some way to mask the code? or make it unchangeable? We've also had issues in the past where SQL code / values are exposed and were able to be changed. That too surprised me. That was fixed with some back-end programming (the HTML could still be modified).
In the screen shot, the ID # can be changed and so the user can see another user's info, by either guessing another's ID or sleuthing to find someone specific's ID.
Inspect-HTML-and-change.png
I added the Crystal Reports topic because the image mentions Business Objects.
What are all tools you using?
ASKER
Swatantra,
Oracle Designer generates the HTML, then it just runs normally. But it's a very outdated tool, although it still works.
In this particular scenario, we are passing an ID to a Business Objects report. But the issue is being able to modify the HTLM via Inspect.
I really thought the HTML was read only, and it seems odd to me, from a security perspective, that it can be so easily modified.
Oracle Designer generates the HTML, then it just runs normally. But it's a very outdated tool, although it still works.
In this particular scenario, we are passing an ID to a Business Objects report. But the issue is being able to modify the HTLM via Inspect.
I really thought the HTML was read only, and it seems odd to me, from a security perspective, that it can be so easily modified.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>In this particular scenario, we are passing an ID to a Business Objects report. But the issue is being able to modify the HTLM via Inspect.
I think the issue is deeper than doing a view source to get the URL: You mention passing an ID to a report. I have an id to pass. Can I not just pass another id and get the same issue: Someone else's data?
As mentioned above, on the web, once the variables are known, you really cannot stop anyone from altering things.
For example, I send you this link to my favorite query (OK, not really my favorite but holiday relevant):
https://www.google.com/search?&q=watermelon
How hard is it for you to change it to cantaloupe before opening it or passing it along?
I think the issue is deeper than doing a view source to get the URL: You mention passing an ID to a report. I have an id to pass. Can I not just pass another id and get the same issue: Someone else's data?
As mentioned above, on the web, once the variables are known, you really cannot stop anyone from altering things.
For example, I send you this link to my favorite query (OK, not really my favorite but holiday relevant):
https://www.google.com/search?&q=watermelon
How hard is it for you to change it to cantaloupe before opening it or passing it along?
ASKER
Chris,
>>You say a user can edit the ID and view someone else's info. That tells me that you dont have a very robust security model in place. You would probably want to address this with a different security model.
- bingo. It's a bigger issue than just this one report.
mlmcc,
>>That said there are other methods of using the OpenDocument that encrypt the user id or you could not pass it and then a login page will appear so only validated users could login.
- The issue with that is you can refresh the page, and the parameter dialogue window shows up, then just type in another ID (which is still a guessing game, it's not a directed attack)
slightwv,
>>For example, I send you this link to my favorite query (OK, not really my favorite but holiday relevant):
https://www.google.com/search?&q=watermelon
- right, but that's a URL in the search window. I just assumed the HTML was not editable. But sure, copy the HTML to a notepad, edit, and run.
-------------
Overall, we need a better security model.
Thanks for the responses.
>>You say a user can edit the ID and view someone else's info. That tells me that you dont have a very robust security model in place. You would probably want to address this with a different security model.
- bingo. It's a bigger issue than just this one report.
mlmcc,
>>That said there are other methods of using the OpenDocument that encrypt the user id or you could not pass it and then a login page will appear so only validated users could login.
- The issue with that is you can refresh the page, and the parameter dialogue window shows up, then just type in another ID (which is still a guessing game, it's not a directed attack)
slightwv,
>>For example, I send you this link to my favorite query (OK, not really my favorite but holiday relevant):
https://www.google.com/search?&q=watermelon
- right, but that's a URL in the search window. I just assumed the HTML was not editable. But sure, copy the HTML to a notepad, edit, and run.
-------------
Overall, we need a better security model.
Thanks for the responses.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>But sure, copy the HTML to a notepad, edit, and run.
You need a web server to 'run' html. Many programs will display HTML but to post back to execute something requires a web server.
>> but that's a URL in the search window
What you posted in the image was a URL.
Now that I looked at it again, I don't think the ID in the HTML you posted is part of the query string so you shouldn't just be able to change it and get someone else's data.
You need a web server to 'run' html. Many programs will display HTML but to post back to execute something requires a web server.
>> but that's a URL in the search window
What you posted in the image was a URL.
Now that I looked at it again, I don't think the ID in the HTML you posted is part of the query string so you shouldn't just be able to change it and get someone else's data.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@Chris Correct, I wasn't really offering it as real protection, just a way to brush away the laziest snoopers heh...
ASKER
David Kelly
>>You can suppress the right-click with javascript, removing the ability to inspect or view source, but that can be defeated by disabling javascript... @Chris Correct, I wasn't really offering it as real protection, just a way to brush away the laziest snoopers heh...
- still, it's a good option that takes you further up the security spectrum. Not perfect, but better
slightvw,
>>You need a web server to 'run' html. Many programs will display HTML but to post back to execute something requires a web server.
- oh, forgot about that. So back to my main point - I'm surprised HTML isn't read only.
>>I don't think the ID in the HTML you posted is part of the query string so you shouldn't just be able to change it and get someone else's data.
-it's the OpenDocument link for Business Objects to run the report. So just change the ID, and voila, someone else's data.
----------------
thanks again. I'll close this on Thursday. Burgers tomorrow for the USA crowd.
>>You can suppress the right-click with javascript, removing the ability to inspect or view source, but that can be defeated by disabling javascript... @Chris Correct, I wasn't really offering it as real protection, just a way to brush away the laziest snoopers heh...
- still, it's a good option that takes you further up the security spectrum. Not perfect, but better
slightvw,
>>You need a web server to 'run' html. Many programs will display HTML but to post back to execute something requires a web server.
- oh, forgot about that. So back to my main point - I'm surprised HTML isn't read only.
>>I don't think the ID in the HTML you posted is part of the query string so you shouldn't just be able to change it and get someone else's data.
-it's the OpenDocument link for Business Objects to run the report. So just change the ID, and voila, someone else's data.
----------------
thanks again. I'll close this on Thursday. Burgers tomorrow for the USA crowd.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I am assuming the reports are being viewed from outside you internal network.
Why do you expose the reports through the open document call rather than having the report run and present a PDF?
mlmcc
Why do you expose the reports through the open document call rather than having the report run and present a PDF?
mlmcc
ASKER
slightvw,
>>I likely don't need the HTML file to make the call. I can just copy and paste that URL into the browser and bypass the initial webpage.
- Mostly true, but there is a logon component that happens in the ERP screen. So the login would only work for that browser session.
mlmcc,
>>I am assuming the reports are being viewed from outside you internal network.
- same network, different server.
>>Why do you expose the reports through the open document call rather than having the report run and present a PDF?
- sounds good, but still you're calling the report with the ID, just producing a different output. But worth investigating, I can ask my colleagues.
--------
thanks again.
>>I likely don't need the HTML file to make the call. I can just copy and paste that URL into the browser and bypass the initial webpage.
- Mostly true, but there is a logon component that happens in the ERP screen. So the login would only work for that browser session.
mlmcc,
>>I am assuming the reports are being viewed from outside you internal network.
- same network, different server.
>>Why do you expose the reports through the open document call rather than having the report run and present a PDF?
- sounds good, but still you're calling the report with the ID, just producing a different output. But worth investigating, I can ask my colleagues.
--------
thanks again.
>>So the login would only work for that browser session.
A report is opened via the "process" so authentication is passed to the report somehow. I could be wrong but I'm betting the report URL can be copied once I have authenticated.
A report is opened via the "process" so authentication is passed to the report somehow. I could be wrong but I'm betting the report URL can be copied once I have authenticated.
Is the id a user's BO ID?
In that case why not use their logged in id to get it and there is nothing to change. Or are the users not logging into the BO system?
I just checked you already are displaying the report as a PDF. I don't think that has a refresh capability.
mlmcc
In that case why not use their logged in id to get it and there is nothing to change. Or are the users not logging into the BO system?
I just checked you already are displaying the report as a PDF. I don't think that has a refresh capability.
mlmcc
ASKER
slightvw
>>A report is opened via the "process" so authentication is passed to the report somehow. I could be wrong but I'm betting the report URL can be copied once I have authenticated.
- authentication happens upon opening the screen, via a server side script, and using the common user id that all standard reports use to connect to Business Objects. So the URL would only work in the same browser session.
mlmcc,
- it's a common id for all users who run reports out of the system. Only Ad hoc users get their own id. Per above comment, authentication happens upon opening the screen, via a server side script, and using the common user id. Not sure about "sObjectFormat=P", but it comes up normally as a Business Objects (Web Intelligence) report, with the parameter (ID) passing in so the report just pops up with the appropriate results.
>>A report is opened via the "process" so authentication is passed to the report somehow. I could be wrong but I'm betting the report URL can be copied once I have authenticated.
- authentication happens upon opening the screen, via a server side script, and using the common user id that all standard reports use to connect to Business Objects. So the URL would only work in the same browser session.
mlmcc,
- it's a common id for all users who run reports out of the system. Only Ad hoc users get their own id. Per above comment, authentication happens upon opening the screen, via a server side script, and using the common user id. Not sure about "sObjectFormat=P", but it comes up normally as a Business Objects (Web Intelligence) report, with the parameter (ID) passing in so the report just pops up with the appropriate results.
The sObjectFOrmat=P is supposed to produce a PDF.
Does the ID affect the data being shown?
mlmcc
Does the ID affect the data being shown?
mlmcc
ASKER
>>The sObjectFOrmat=P is supposed to produce a PDF.
-- hmmm, I'll look into this with my colleague, he's not back until Monday. But it definitely brings up the report normally in Web Intelligence
>>Does the ID affect the data being shown?
-- Yes, it's the student ID, who retrieves course and grade info. But if they change the Id, they can get someone else's grades, but it's a total guess on the ID.
-- hmmm, I'll look into this with my colleague, he's not back until Monday. But it definitely brings up the report normally in Web Intelligence
>>Does the ID affect the data being shown?
-- Yes, it's the student ID, who retrieves course and grade info. But if they change the Id, they can get someone else's grades, but it's a total guess on the ID.
ASKER
notes from some other developers I contacted individually, and who know the system I'm working on:
Deveoper 1:
"The only way I can think of doing that would be to make it harder to view...either by using javascript to add an event Listener to activate a location or by hashing the URL and passing it to a function using onClick()."
Developer 2:
"You can make it harder for the user to understand by hashing it or moving it a few steps away like [Developer 1] mentioned, but client side code (like HTML) is inherently insecure
To really secure it, you need some sort of check or encryption/decryption on the server side that the user isn't privy to and can't modify."
Developer 3:
Maybe a way to handle this is through an encrypted checksum that is included in the url that is generated based upon the form parameters and their values. If the checksum calculated doesn’t match, the query fails. I could be wrong, but I am thinking that is how Apex handles this sort of thing. You can specify through security setup that a checksum is used to validate a page query and that the url/query have not been modified. Otherwise the query fails, throwing a checksum error. Could you write something manually through a set of database procedures, maybe? Not saying it would be easy.
Deveoper 1:
"The only way I can think of doing that would be to make it harder to view...either by using javascript to add an event Listener to activate a location or by hashing the URL and passing it to a function using onClick()."
Developer 2:
"You can make it harder for the user to understand by hashing it or moving it a few steps away like [Developer 1] mentioned, but client side code (like HTML) is inherently insecure
To really secure it, you need some sort of check or encryption/decryption on the server side that the user isn't privy to and can't modify."
Developer 3:
Maybe a way to handle this is through an encrypted checksum that is included in the url that is generated based upon the form parameters and their values. If the checksum calculated doesn’t match, the query fails. I could be wrong, but I am thinking that is how Apex handles this sort of thing. You can specify through security setup that a checksum is used to validate a page query and that the url/query have not been modified. Otherwise the query fails, throwing a checksum error. Could you write something manually through a set of database procedures, maybe? Not saying it would be easy.
ASKER
Thanks for the discussion, really helpful.