Some pages, such as amazon and Gmail, separate out the HTML Input fields for E-Mail and Password onto two different HTML pages, one after another.
What is the rationale for this approach instead of asking for credentials on just a single page with one HTML Form that has two Input fields at the same time?
Most of the times this happens with federated identity, when multiple identity providers can actually log you in. For example you can use your company identity provider (ie. login server) to log onto a 3rd party resource which trusts your company IdP.
But the question is then how you choose which provider to use in the 3rd party, if they accept several. And this is one solution: you enter your email address, and your email is associated with your IdP, so you can be redirected to the correct login page (from where you will be redirected back). Of course, your IdP can easily be the site itself, in which case the process looks rather silly.
Note that you can be redirected to the "local" password page regardless of whether your username is actually correct or not, and usually only the domain part of the email is used to decide where to redirect, so it is less of a security issue, user enumeration is still not possible. But you can try and enumerate valid identity providers.
Related
I am trying to redirect my user from a html page to a jsp page which has been deployed on tomcat/webapps using .war file.
While doing so, I am also sending the session information of the user as an hidden parameter via POST method.
With the help of burpsuite tool(security testing tool) one can easily manipulate the cookie and change the username of the user logged in. How will I be able to block such kind of cookie manipulation?
You cannot control/prevent what the browser/client is sending, so do not consider the data received as fact/true. Your application shouldn't just look at the username and say "oh, it's the admin user, I show the whole admin area".
To prevent tampering the data originated from the server or at least detect changes, you use encryption or digital signatures. With encrypted data, it is not possible to change the data. You don't know how to decrypt the data and encrypt the changed data correctly since you don't have the encryption key to do so. With signed data you can still read the data but the signature makes sure that you can detect, if the data has been changed.
In your case, you can use a JWT instead of just the username. The JWT contains a digital signature which is used to check if the data has been changed. Your "testing team" can change the data but your server can see immediately that it has been changed and reject the received (changed) information.
I am writing a simple mailing application, however I am not yet aware of the full capabilities of HTML editing within the mailing world.
I would like to give the website administrator the choice to accept or to refuse a reservation by sending him an overview of the reservation. Below in the mail I had 2 buttons in mind, accept & refuse.
I tried using a form within the HTML e-mail but almost every mailing client blocks this out.
Is there another method to do a http post command to let's say myserver.com/accept or myserver.com/refuse from within an e-mail without having to open an additional webpage?
If not, what is the best way to achieve such things?
This is a pretty relevant article: https://www.sitepoint.com/forms-in-email/
Basically he concludes that support is not reliable so you should not use forms in emails which I agree with.
Since you say you want to give this choice to a website administrator I think you probably want some sort of authentication. So I could see it working something like this...
Send the admin an email containing two links mysite.com/reservations/:reservation_id/accept and mysite.com/reservations/:reservation_id/refuse.
Admin clicks on one of the links
Link opens in the browser and your site(controller -> ReservationService) accepts or refuses based on the id and action in the url
You will have a few things to consider, such as authentication(I assume you already have this since you have the notion of website admin?), authorization(can this admin accept or deny the reservation?), does the reservation exist, has the admin already accepted or denied the reservation, etc.
I send 3 different links to people on a daily basis. I know the name of the person I am sending the link to. How do I attach that persons information to the link to know they clicked on the link?
I sent close to 50 emails to different people. I just want to be notified that someone I sent the link to click on it.
You need to use a database for this. The link could contain a random hash that can be looked up in the "emails" table. This table could keep records for timestamps, specifically when the emial was sent out, and when the user clicked the link.
#QUESTION:
Most hosting providers give you the option to hook up a database. If you have trouble finding this, use google or their support. As far as how to "use" a database, you will need to learn this in you own time. But like anything else the basics are widely available through google, which in your case, is all you need to finish your project.
You can add an encrypted or obfuscated field to your URLs identifying the email address.
Common methods:
base64 encoded email address XOR-ed with known key
md5 hash of email address truncated to first N characters
And so on.
The first method allows you to reverse the process (i.e. getting back the email address from the visit log), the second is one-way only.
For example, using the second method with email dude#gmail.com (truncated to 12 characters):
http://domain.com/click.php?v=ec3ab9422d7a
Or, as already said, you can simply use a database and store a key-value pair (email, hash) with, for each email, a random string generated on-the-fly by your massmailer.
This is somewhat of a newbie question I'm sure and I hope the community will excuse me for not knowing this (or not knowing the appropriate search terms to resolve my question).
So, this is the deal: I'm running a small webpage with a small amount of visitors. I've written the whole page in HTML and CSS myself and I host it in my private DropBox (http://dl.dropbox.com/u/3394117/Hemsida/Psykofil/Index.html).
I've bought the domain name "www.psykofil.org" from Loopia (www.loopia.se) and I've directed this domain to the index.html file referenced to above.
Now, this is what I want to happen: I have three different places you can go to on the page (you choose where to ge through a menu on the left). When one of these links is clicked, it takes the user to another .html-file. What I would like to happen here is that this is seen in the adress field so when he or she clicks on "x", it should say www.psykofil.org/x on top. Also, when he or she navigates away from the webpage through a hyperlink I would like the adress field to update to show the new location. Right now, no matter what the user does, it always says www.psykofil.org in the adress field.
I probably should mention that my options (freely translated from swedish) when I go to the configuration of my domain name at Loopia is the following:
DNS
Parking
Forwarding (the one I'm currently using)
Send to an external URL
(Unavailable because I don't have a web hotel with Loopia) Point to another domain in the account.
(Unavailable because I don't have a web hotel with Loopia) Own homefolder for webpage.
That's because your page is inside a <frameset>, so the address bar will never update.
You say "I've directed this domain to the index.html file referenced to above." It sounds like you've set up 'domain forwarding.' Framesets are often the 'trick' hosts use to keep the same URL - embedding the pages you're 'forwarding' to in a frameset. It's called "domain masking." See http://www.hostingmultipledomainnames.com/domainforwarding.htm for a description of how it works.
If you upload your actual html files to your site root, that should do the trick. If you're not sure how to do that and you're a new webmaster, you may want to be in touch with your web host's support. Otherwise, if you want to have that domain, but keep your files in your dropbox account, your options I believe get complicated (things like reverse proxies).
UPDATED:
Typically, when people create a website, they do three thing: register a domain, buy a web hosting account, and then associate their domain with their hosting account. You've done the first part, and have found a clever way of managing the second part, but you haven't done the third part.
The process is like this:
You register your domain. I.e., you pay $10-30 a year for the exclusive right to a given domain name. Registering the domain means that when people type 'http://mysite.com' into their browser, your domain will come up. However, it's just a placeholder - there isn't any real content there. All your files and images need to be uploaded to a server in order for people to see them.
You purchase a web hosting account. Or in your case, you upload your files to a publicly-accessible server, which has the advantage of being free. You then upload all your content.
This is the part you're missing. You now need to associate your domain name with your hosting account. This typically happens without your intervention when you purchase both your domain name and your web hosting account through one company.
However, if you acquire them separately, you need to do two things:
a. Log in to your domain registrar and point the domain name to your server for your web hosting account. This is a signal to the Internet - hey, when you type in the domain name 'http://ssss.com', go to this server.
b. Log in to your web hosting account and "park" the domain at your account. This may be hard to understand at first, but basically, just telling the Internet to go to this or that server when typing in your domain name isn't very useful.
If that's all we needed to do, I could just register http://my-amazon.com and point my domain to Amazon.com. Then people could surf Amazon.com as http://myamazon.com and I could get rich from selling this now incredibly popular domain.
But that doesn't work. In order for me to actually browse the web hosting account through my domain name, I need to "add" the domain name to my hosting account. Dropbox doesn't let you do that. It's a file-sharing system, which you've cleverly used as a web host. However, you'll never be able to log into Dropbox and park your domain there, because that's not what they do.
Summary: You can think of this process like a pass in basketball. You can throw the ball by sending the user to a server, but the server has to catch it. In order to catch the ball, the server needs to know it's coming.
Your domain registrar is 'faking' this process by adding one page to its own server, which links to "http://dl.dropbox.com/yourpage/etc/etc/Index.html". This way, your domain registrar doesn't have to worry about hosting all your content and the headaches of technical support and server space.
The downside is, you don't have a webhost that allows you to park a domain at the moment. The upside is you're saving about $60-100 per year (it might be more or less in Sweden), which is what a basic "shared" hosting account would cost.
You can decide if having distinct webpages (http://psykofil.org/contact.html" etc), is worth it for you, or whether you're fine for now with the very low-cost solution that isn't perfect but at least allows people to access your site. What you've come up with is actually pretty cool, but it does have some limitations.
Finally: If you do want to go ahead an buy server space so you can host your site, it will be less of a headache to buy it through Loopla, if the price and service are good. Typically, you are given the option when making the purchase of linking your account to your already-registered domain name. Then all you need to do is use an FTP program like Filezilla to upload your content to your account, and you're done.
It seems your host is "masking" the URL, meaning actual index.html page located at "www.psykofil.org" is in fact, loading your index page located via dropbox into an "iframe" , hence your main URL does not change to reflect the changes.
Solution: Upload your file to your main host and change the default index file that has iframes with the dropbox index file.
I believe it's because you're using frames. Were you to simply link to the other html page(i.e About page) then the address bar would update.
I'm building a site that offers functionality to users without requiring them to register. The idea is to send an email to the specified address containing a link with a token. That way the user would could this link anytime they want to make changes to the functionality.
While I realize that there is no way to truly secure such a concept, I'm looking for options to minimize the visibility of the token. In its current state, soon as the user clicks on the link it is added to their browser history, available to anyone who has access to the computer.
In most cases I would over come this with a simple form so that the token could be passed through with a POST request, but forms aren't really supported in emails.
So the question is, does anyone know of an alternative way to hide a token in such an email?
I'm sure you've thought of this, but you could send them a password and a link to a URL where they'd need to enter that password. If the emailed URL contained another password, it would be a smaller compromise to security than usual to make the user-entered password quite short, like a PIN number, say.
You could resend a new token every time the user wants to log in. Have them plop in their email address and send them a new token, while setting previous tokens to 'expired.' Or, if the server detects that an old link/token was used, it could automatically send a new one to the associated email address and ask the user to check their email for a new link.
That would require keeping track of old, expired tokens and the associated email addresses, but still requires no registration - just that a user check their mail every time they want to log in. You'd essentially be piggy backing on their email authentication.
It'd also be counter-intuitive for users.
This would turn the token into a cryptographic nonce, which is primarily used to prevent the replay attack you mentioned.
Another answer, perhaps more useful:
Some browsers (like Chrome) do not record 301 "Moved Permanently" redirects in the browser history. Firefox does, but there's a proposal to change that:
https://wiki.mozilla.org/Browser_History:Redirects
For example, in Chrome, if you navigate directly to
amazon.com
it will follow a 301 Redirect to
www.amazon.com
If you then check your browser history, it will only show
www.amazon.com
Thus, if your server returns a 301 redirect from the login link, the server could record the token, remove it from the redirect link, and the user's browser would only record the redirect link.
(this is my first time responding on stack overflow - let me know if my writing is unclear or if I'm missing other etiquette)