Today i got confused when i was asked What is Cross browser scripting. Here as per my understanding Cross browser Scripting is related to Browser compatibility, Cross Site Scripting is related to java-script hacks & Cross Domain Scripting is related to Ajax calls.
I tried to google it also but not getting clear concept of cross browser scripting.
Please help me to understand the difference.
If a script is cross browser, it works comparably in all browsers. JavaScript engine in different browsers tend to vary in some minor details.
Cross domain scripting is either an attack that tries to hijack user sessions (malicious) or it's a way to communicate with another domain. Cross Domain Scripting aka Cross Origin Resource Sharing is quite tricky to set up.
"Cross-browser Scripting" is a somewhat archaic term (you'll see the article linked is dated 1997) meaning writing scripts that work across browsers. More recently this is usually called "browser compatibility".
"Cross-site Scripting" is a type of attack that involves making malicious scripts a part of someone elses page in order to deliver some payload that compromises their visitors.
"Cross-domain Scripting" is generally synonymous with "Cross-site Scripting".
If you have a cross-site scripting attack that works across all browsers, you might be inclined to call it a "Cross Browser Cross Site Scripting" attack, or XBXSS.
Related
Is there any way to send ASCII symbol/character to USB via webpage (HTML)?
We have a local PC with a webpage running in kiosk mode. The webpage have a button that should send that symbol/character to USB. How it can be done?
Thanks for any help.
No.
Code running in web pages is sandboxed and has no direct hardware access in general and definitely no direct USB access.
It may actually be possible, though only by using an experimental feature that's only available in some browsers.
More specifically, there exists a draft specification of the WebUSB API which aims to give access to USB devices from the browser, albeit with some limitations for security reasons. For instance, Chrome requires the page to be served over HTTPS.
This feature is currently implemented in newer versions of Chrome and, according to MDN, Opera.
There is some more information about it on Google's blog.
Question is:
Is there any way to send ASCII symbol/character to USB via webpage
(HTML)?
I don't know if Electron Apps is what you call a webpage, but it is to me. If Electron App enters your usecase, you can access the NodeJS API, and therefore your machine.
This could be the answer you are looking for, if the only limitation you have for your question is the use of web languages (HTML, CSS, Javascript). If your limitation is give access to the world through a classic web browser, as #Quentin sayed in his answer, it is not possible.
Thanks god it's not possible.
I would like to ignore X-frame header on my website so that iframe can load external websites. There are chrome extension like
this one which works perfectly. How can I implement same concept through javascript?
You can’t use frontend JavaScript code running in a browser to cause the X-Frame-Options response header to be ignored. X-Frame-Options is a security feature designed in part as a defense against clickjacking attacks. If any site could just use some JavaScript code to cause browsers to ignore X-Frame-Options, that would pretty much make it completely useless.
That’s the reason why the only way you can cause it to be ignored in your own browser is by intentionally opting-in to insecure browsing by installing an extension as mentioned in the question.
But you can’t use JavaScript to force insecure browsing on other users by bypassing security features like X-Frame-Options that browsers have built-in support for.
I implemented an edge extension where my popup has embedded iframe while loading the popup, it throws an error i.e.
SEC7111: HTTPS security is compromised by ms-browser-extension://SecureInput_55A39EC1FD424BE88AD67FFE91F90A63/pages/notification.html
SEC7111: HTTPS security is compromised by ms-browser-extension://SecureInput_55A39EC1FD424BE88AD67FFE91F90A63/scripts/lib/underscore-min.js
How to fix these issues?
We're aware of this issue and are tracking it publicly: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8748330/
From what we've seen in our tests, however, these exceptions are merely cosmetic (i.e. we're displaying the message, but do not actually prevent the loading of any resources).
If you are actually seeing resources being blocked, please let me know, as this is something we are not aware of.
Today I attempted to browse a new feature recently deployed to our testing environment (NOT LOCAL). After navigating to the new feature I was met with a blank page. Confused, I checked Chrome's console and found an error:
XMLHttpRequest cannot load https://test.mytestsite.com/SomeApplication/api/SomeController/SomeMethod/8?Id=523283&SecondId=1612w3426653.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://test.mytestsite.com' is therefore not allowed access.
This code makes an ajax call to a WebAPI (on the same domain) to retrieve some information on document.Ready. I understand the error and I'm familiar with it's typical cause. However, this call is being made from within the same domain AND it works for the other developers on my team.
Symptoms:
- Does not work for IE or Chrome/Incognito
- Does work for FireFox
- Works on all browsers for at least 4 other developers on the same domain that I reside on. (Indicating to me that this is an environmental issue)
Possible causes:
- I was doing some CORS research several weeks ago and perhaps I configured some Windows 7 setting to cause this to happen?
Google is saturated with the standard CORS issues, so I'm asking here and hopefully someone can help.
The issue at hand was due to inconsistencies between environments.
In our production environment SSL is enforced with a redirect in IIS, while in our testing environment it is not. I was navigating to the site via a bookmark using http. Updating the bookmark, as #epascarello suggested, fixed the problem.
As I understand, the webserver will send p3p information to the browser, but will the browser then present that data to the javascript engine via some API?
No -- P3P information is not exposed to JavaScript, and generally has very little effect on browser behavior in general, other than a few weird edge cases on MSIE.