I have a client web application that allow users to LOCK the screen without the need to log out from the application, this action just hides the elements on the screen and show a lock screen.
Obviously, when I inspecting the elements on the page I still can see the elements on the page and their data.
What is the best solution to hide the elements from the inspect html? storing the html on javascript parameters and removing the html from the page will be a good solution for this problem? I'm just thinking of it and it seem that their is not a secured solution to hide data in html
If your lock is for security reasons then it's better to implement a server-side lock and move the user to another page (saving the page state and restoring it afterwards). Messing with the markup using JS is more complicated and everyone can fool your logic by disabling or executing some inline JS with a debug tool.
The only option is get html content, store it in, say, localStorage encrypting it with password, which user should input and don't save that password. Then when user returns, prompt for password again and decrypt content.
Server-side solution with logout/login should be simpler, though.
Anyway, you'll need to identify user in order to protect your app from unauthorized usage of another person.
Related
I have a react app. I need to send a user to fill a form(s) on an external page (in another domain), and then get back with the result (success/fail) of the form submitted there, to continue the process in my react app.
I don't control the other domain or the app there (it is a 3rd party), but I can ask them to make changes (and maybe they will agree, if it is not too complex).
The external forms are not html only, trey have javascript in them as well (for example to autocomplete cities names, etc).
How can that be achieved?
I thought about few options:
Iframe + postMessage
Popup + postMessage
Redirecting, and asking them to change site so they will redirect back to me on form completed.
Asking them to make a special form just for me that I can embed inside my design.
Issue with 1,2,3 is that it will show the entire external page, which has not just the form, but also other links, so user can get "lost" and never come back.
Is there a simpler way to do that? The less I need to rely on them to make changes the better, and if I can avoid iframe/popup/redirecting and show the form inside my app is better
I'm looking to securely lock content on a basic html site based on various permissions of the user. I'm looking to have a pop-up modal appear when the user's permissions don't check out... however it seems to be that any savvy user could simply open the console and delete that element (thus revealing the page anyways).
What am I missing here? What's the best way to approach this so that no matter what the actual page can't be accessed?
Thanks in advance for the help!
If content is downloaded to the client, it's always technically possible for a savvy user to access it.
You can either live with that, or alternatively do something like the following:
Load the basic page template without any content
Use an API call using cookies/other auth to get the content
If logged in, display the content, if not, launch the modal.
Ok here is my answer to this one.
The answer given was agood one, you can't hide the content truly so your options are:
Don't download all the stuff you want until you have auth'd the user (via cookies etc.
Use a simple redirect/buffer page infront of your hidden content.
In my use case (shopify) partial downloading of store content isn't exactly configurable (or i don't have enough knowledge of their template language + theme design to pull it off!), so I made use of javascript and cookies in order to check a user's status. If the user didn't pass they'd get kicked back to a landing page. Good enough!
I hope to explain what I need in a clear way.
I have a site (which uses Javascript and Jquery) which should be accessed only by customers who are in good standing with payments, and I recognize them reading a server side database.
The mechanism works pretty well, but there is a minor problem which should be addressed.
After the validation check, if further site access must be blocked I use the following brutal code to show a message in a DIV (id=noway) and then stop any operation:
$("#noway").html("<p>You are not allowed to proceed since your payments are overdue</p>");
while 1{}
Problem: the DIV does not show anything until the browser's (mozilla) timeouts with a 'script in the page has stopped...continue..exit...' message.
It seems that Mozilla enters the infinite loop before of completing the DIV update. What can I do?
Besides this, is there any other more elegant way to block any further visitor activity?
Actually I thought to redirect the visitor to a different page with just the advice, but I would prefer not to do in this way, if possible.
Thanks
I think the best way to restrict site access is to do it server-side. Your page shell read the server-side database before it build any client-side output. So, if the user is not authorized, than the only page content shell be the message about the payment. And only if the user is OK, then the page outputs all the regular contents.
When I am using iframes or frames (older sites), as a extra security precaution I use the JavaScript function:
<SCRIPT LANGUAGE="JavaScript1.1">
if (top == self) self.location.href = "../index.cfm";
</SCRIPT>
then another hidden check to see if the page is being called correctly....
<cfif (HTTP_REFERER DOES NOT CONTAIN "referer_page.cfm")
<cfabort>
</cfif>
It works great to keep visitors (hackers?) from opening and/or trying to post to the page.
The problem is that the JavaScript displays in source code and the less they know...
I know the JS is client side but is there anyway to create the function in the server side CF or otherwise hide from prying eyes?
I a running cf9 on my and most of my client sites.
Thank in advance
No, it is not possible for any server side language to tell if the client that requested a page intends on displaying it inside of a frame. The only way to tell that is to ask the browser once your page reaches it.
What's the concern with the Javascript being visible?
There is literally nothing you can do to permanently avoid clients from seeing your source HTML and/or Javascript. Any attempt at security on the client side is in the end futile. You will keep out casual (i.e. non-web developer or programmer) users, but that is all. Anyone with a rudimentary knowledge of HTML and access to Google (or Alta Vista or ask jeeves for that matter) will be able to circumvent your barriers.
The use of HTTP_REFERER is suspect here as well (I know I know... I'm a negative Nellie :). That CGI var is dependent on the browser and web server working together. It will not be reliable overall because it is dependent on the client side. Someone up to no good will have no problem circumventing your barrier by simply constructing requests with the appropriate referrer.
If you want server side security then you are forced to use some form of authentication and session. This is a growing field what with oAuth and the use of Google, FB, Twitter etc as federated authenticaiton services. But plain old usernames and passwords tied to login sessions works too :)
To be clear, #Luke is saying that some users properly using your site, viewing iframe content, may have problems if they have a security setting, like an anonymity program, blocking their data, like cgi variables.
The only real solution is proper authentication and filtering on every page. If a list shows content for a user and loads details into an iframe, the iframe's page must also check that the user has access. At that point, it doesn't matter if they can get at the url.
For instance, if you get a list of user images like this.
<cfquery name="getImageList">
select imageid,imagefilename_mini
from images
where userid = <cfqueryparam value="#session.userid#">
</cfquery>
Which loads an iframe to load full sized images, you still need the and subclause
<cfquery name="getThisImage">
select imagefilename from images
where imageID = ...
and userID = ...
</cfquery>
That way, even if someone changes the image id in the url, it still only lets them see content bound to the userID.
Also, modern browsers make altering the source of a live page all too easy. I don't mean that browsers can alter the server side file, I mean that contents of the DOM as delivered to the browser. It's an incredibly useful tool for developing and debugging, but it does make mischievous/malevolent activity easier.
In chrome and firefox, you can inspect an element, change the attributes and the page will change before your eyes. Here, that works for iframe src's, so it still is within the DOM it expects to be in.
You should regard client side UI as how you'd like the page to be presented, and the way it works best but use server side safeguarding (proper validation) because it's too easy to get around client-controlled data/elements.
I have a web page which needs to do the following:
dynamically create an HTML fragment using JavaScript
open a new window
display the HTML in the new window
My first approach used document.write to copy the HTML into the window. This works in most cases, but it causes problems with Internet Explorer when the original window has set document.domain. Plus document.write tends to be discouraged these days.
So my second approach was to put the HTML into a hidden form, set the form's target to the new window, and POST the form. This means I need a script on the server to respond to the form, by echoing the POSTed content.
But this is dangerous, since someone could make a request that includes <script> tags in the content. How can I avoid the potential XSS risk? I guess I could filter out things like <script>, although that seems clumsy. If I were creating the HTML on the server, I could encrypt it, or add some token that can only be verified on the server. But I'm creating it on the client.
EDIT: Thanks for the filtering suggestions so far. I may choose to go this route, but I'm wondering: what if I don't want any restrictions on the HTML I create? Is there any way I can validate that the document was created by my page?
Try HTML Purifier.
Edit:
"Is there any way I can validate that the document was created by my page?"
Not unless you create another copy of the html server-side and compare. Anything in your script can be viewed by the user, although you can make it difficult for non-technical users. Anything that client-side Javascript can do, a malicious user can do on a Javascript console.
Even if you somehow verified that the request came from your script, a malicious user can modify your script using a Javascript console by inserting lines of code that produce a dangerous request. All GET and POST data must be treated as malicious.
Try PHPIDS.
PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt. This could range from simple logging to sending out an emergency mail to the development team, displaying a warning message for the attacker or even ending the user’s session.