I'm curious if chrome extension overlays are delivered securely and unadulterated, and whether or not someone can "listen" to internal events.
If a user were to enter a password via a chrome extension, could I guarantee that no other browser script has recorded the password? I will hash the password with 2FA so the network request is secure, but I'm curious if anyone can get the innerHtml of an <input> within a page action.
I'm asking because I know that generally iFrames are insecure if they're hosted in an unsecure environment where they could be "replaced" with lookalike, man in the middle, phishing palettes
Thanks
Only if you injected some element into a web page it will be a part of the web page (e.g. code in an injected <script>) open to any other page script.
Internal pages and scripts of an extension like page action or toolbar popup or background page and even content script environment (variables/functions) are inaccessible from the web. With a few exceptions, you can't even directly access one from another inside your extension as those are just like different tabs/windows: messaging should be used.
The only way a web page can know what happens inside your extension is to explicitly provide it with the information from your extension. You would have to explicitly send the info via DOM messaging, for example. Or via an explicit externally_connectable mechanism.
Maybe other scripts can't record the password, however you would also need to protect the input from native components like KeyLogger, they can always get what you typed before bubbling up to browser process. So I guess a native component is also needed, it could fight with malicious keyloggers and ensure they can't get valid user input.
Related
We have a native app and an Alexa skill. You can't use the Alexa skill without the app and you need to have your app account first. Some users are creating accounts with the Alexa skill that aren't linked with their app accounts.
We can disable self-registration and the sign-up link goes away in the hosted UI, but it also prevents account creation from the application using Amplify.
I looked at the hosted UI customization CSS to see if I could style that link to hide it, but the CSS customizations don't seem to address that link specifically. I'd like to avoid reinventing the entire auth wheel just to get rid of that one link.
Is there any way to disable the "sign up" link in the Cognito hosted UI without disabling self-registration?
Thanks!
You have 2 options as far as I know.
Use custom lambda trigger on signup to reject calls made from your hosted UI
Use your own login page instead of hosted UI.
Unfortunately, there is no way to modify the contents of the UI. You can only change the CSS and add a logo.
The first method is easier but is a bad implementation because you are confusing your users with a button to register but then rejecting all their attempts. Second method is the best way to achieve what you want.
Another method is to use the adminCreateUser function, give it a temporary password and suppress email sending of the temporary password. Then do adminSetUserPassword to give the user the desired permanent password.
This technique seems to work properly when the "Enable signup" feature is disabled.
I'm enjoying developing cross-browser web extensions, the main target being Chrome, so much that I started to think to develop one for my company. I find a chrome extension quite a cheap and efficient way to deploy internal apps. The main purpose is to host a couple of dynamic dashboards that fetch data from various APIs by using cross-domain ajax in background scripts. I finalized the app and I was also able to implement the authentication via chrome.identity and Azure AD.
However, I am struggling to find a safe way to customise the content.
I mean, when the extension is installed it requires to login to azure via the chrome.identity flow. Then I get a token that I use to query ms graph and get the user ID, name, email and basic info.
Until I get this information I want the browser action (popup) to be unavailable to the user as well as any other extension pages. After a successful login I would like to show the content on the pop up and to let the user access the pages, but here I want to customize the experience.
I know how to use the user id retrieved from the api call to customize the extension, but I think it is not safe because all the code is in the client.
If I code something like
if (user === logged) show something
it will be damn easy for a malicious user to look at the code and bypass it, or even to impersonate another user. And chrome extension cannot be obfuscated.
Any help?
Thanks
I have the following very specific bug in my web application, caused by a curious interaction between the History API and the way Chrome caches pages.
User A logs in and uses a page like /home on the site. This page is an SPA type page that uses the History API to maintain a history stack as you navigate within the page. So as you do stuff, the url may change to /home/with/new/state This page also has a message like "Hello, User 1" on it.
User A logs out of the application.
On the same computer and browser, User B logs in and goes to /home, /home/with/new/state. Again, this is not a true navigation, just modifying the url via the history API.
User 2 clicks some link to navigate (for real) to another page on the site.
User 2 clicks the back button
The browser goes back to /home/with/new/state, but to the cached version that still says "Hello, User 1" on it.
Naturally, this is really confusing for users.
I can fix this by setting a more aggressive cache-control policy, forcing a reload of the /home page, but that would increase bandwidth to the site. The vast, vast majority of the time, the existing caching is fine, because the user isn't changing, so I don't really want to do this server side, for all users, always. It also is only an issue in Chrome; somehow the other browsers handle this correctly. I'd prefer a mechanism to bust the cache ONLY when I have this situation of a user change.
How might I accomplish this?
is there any way that I can inform the google bot that to get additional languages it needs to have a cookie set?
for example, at https://www.famistar.com the user can click at the bottom of the page to change language. What really happens under the hood is that the button via js will set a cookie and will reload the page.
Is there any way (withought modifying the urls or adding a url parameter for language) that we can notify google bot to crawl all provided languages?
Google can't ready cookies and sessions, and to prove this user "Web Developer Tool" on any browsers and disable the cookies.
The only way that Google can index and crawl your languages is to add them as a level in the URL "mydomain.com/en" or add them as sub-domain "en.mydomain.com" or parameter.
Also don't forget to add "hreflang" in the to make sure Google will understand your structure.
Currently we have a Hybrid solution where we show a web form in our Movilizer screen. This solution does not open a new browser window, but the form is shown in the movlizer screen.
This form need to be logged in with our credentials (using our login page).
Now we have a new requirement that on referring to the form, instead of our login screen, it will be redirected to a third party authentication login. Once the user is authenticated by this third party authentication, it will be redirected to the our web form.
How can we achieve this?
This must be solved first in the HTML world. Once the auth in HTML is completed (positive or negative), you can use the Movilizer specific Cordova JScript functions to provide the result to Movilizer, so the MEL logic in your Movelets can operate with it.
Movilizer runs HTML through lightweight html engines / browser components out of the frameworks of that specific platform. In other words, Movilizer clients use functionality that the native frameworks provide ... Movilizer does not have impact on how HTML itself is processed in there. Regarding the typical problems different browsers on different platforms normally bring, this means you have to carefully test the HTML part of this process on a multitude of platforms and devices.