Background
I'm working on an application for my own needs, with some very lightweight frameworks. I don't want to spend time on user previlegies, logins and so on. No one but me will use it.
My question
Let's say I want be able to add or delete anything in my database when visiting this address:
http://www.example.com/?secret=eccbc87e4b5ce2fe28308fd9f2a7baf3
No login, just this address. How secure is that? If it's not secure, what would be a good simple solution?
My thoughts
No one can guess that secret key.
Can robots find out about it if there is no link to it?
If its not going over SSL then it can be sniffed too. If you update on public wifi anyone can see the value. Though its quite unlikely anyone will be sniffing for your website
If this it just for yourself, it should be ok. One caveat not mentioned yet - make sure you do not embed other sites' content into your pages, or they will see you magic value in their Referer headers.
Your thoughts are right. So don't bookmark the URL on a public computer ;-)
If its a MD5 or another big text string is up to you...
To answer the the question in the post title "Are GET variables secure for transmitting secrets?", the answer is no (depending on what you mean by 'secure'). As some have pointed out, although the unique URI may not be guessed it could be possible for someone to find the unique URI if they were suitably positioned on the network (coffe shop, room mate, library, university, ISP, etc).
Even if SSL (HTTPS) is used there are some weaknesses in SSL which could still reveal your traffic to a suitably positioned attacker. See SSLStrip [0], BEAST attack [1] and most recently CRIME [2] as well as others.
The real dilema is how much risk are you willing to take. If you are using the URI to view images of kittens, then you may want to accept the risk. If, however, you're using it to store your credit card details, then you may not want to accept that risk.
There are other ways in which your unique 'secret' URI may be revealed apart from packet sniffing. Another way in which it may be revealed is if from that 'secret' page you link to a third-party site and click on that link, the URI may be sent in the HTTP 'referer' header.
[0] http://www.thoughtcrime.org/software/sslstrip/
[1] http://luxsci.com/blog/is-ssltls-really-broken-by-the-beast-attack-what-is-the-real-story-what-should-i-do.html
[2] http://arstechnica.com/security/2012/09/many-ways-to-break-ssl-with-crime-attacks-experts-warn/
Robots will find it if you put it in any kind public in the internet. After knowing the URL and writing a small bot specified for your site it's possible that someone just iter all md5s with a rainbow table. If it's just for a small management it would be ok, but it's dangerous put there some other values to check in it. Maybe the md5 and the sha512 of the same. That's quite secure.
Related
Suppose we have website that use MD5 hash in URL like this:
http://somewebsite.com/XXX/
where XXX is MD5 hash.
Content of this website may have sensitive information like transaction details with personal data.
There is no other authorization to this website, so if you have URL you can access it.
How safe is it? I mean, if no one will share URL with anyone, then can I assume no one will access it?
How much time could it take web crawler, to crawl through all combinations of such url?
I ask because I am using some web shop, that store transaction details with personal data in such manner, I am saying them that it's not secure and someone can view their clients sensitive data, but they are not convinced. To build web crawler it's simple to me, I know how to do this, but I don't know how much time it will crawl through all combinations, maybe at shop they are right? This is not about my website, I am end user of that shop, and I need to convince them they are wrong.
This is an example of "security by obscurity", and it should be considered unsafe.
Just for the fun of it, lets think about it a bit more.
You say it's a hash. A hash of what? Is it possible that a hacker guesses or knows what you are hashing, and starts guessing from there? BTW, how will you ensure that hashes are unique?
Sure, an MD5 hash is 128 bits, but if the thing you're hashing doesn't have 128 bits of information, it doesn't really help. Maybe the thing you're hashing is a sequence number? In that case, guessing the next hash could be trivially easy.
Even then, MD5 is considered broken now, and not fit for security usage. For more information, take a look at the Wikipedia article on MD5.
More importantly, you create these URLs, but you need to send them somehow to the user. How will you do that? Not in a clear text e-mail I hope. Maybe you publish them on a properly secured website, where they can click on the link after properly logging on. Oh, wait... no probably not.
If you want to keep something safely confidential, secure it properly. Require a logon. And use SSL/TLS, i.e. HTTPS instead of HTTP.
I'm currently developing a web application that has one feature while allows input from anonymous users (No authorization required). I realize that this may prove to have security risks such as repeated arbitrary inputs (ex. spam), or users posting malicious content. So to remedy this I'm trying to create a sort of system that keeps track of what each anonymous user has posted.
So far all I can think of is tracking by IP, but it seems as though it may not be viable due to dynamic IPs, are there any other solutions for anonymous user tracking?
I would recommend requiring them to answer a captcha before posting, or after an unusual number of posts from a single ip address.
"A CAPTCHA is a program that protects websites against bots by generating and grading tests >that humans can pass but current computer programs cannot. For example, humans can read >distorted text as the one shown below, but current computer programs can't"
That way the spammers are actual humans. That will slow the firehose to a level where you can weed out any that does get through.
http://www.captcha.net/
There's two main ways: clientside and serverside. Tracking IP is all that I can think of serverside; clientside there's more accurate options, but they are all under user's control, and he can reanonymise himself (it's his machine, after all): cookies and storage come to mind.
Drop a cookie with an ID on it. Sure, cookies can be deleted, but this at least gives you something.
My suggestion is:
Use cookies for tracking of user identity. As you yourself have said, due to dynamic IP addresses, you can't reliably use them for tracking user identity.
To detect and curb spam, use IP + user browser agent combination.
first of all, the question from a naive point of view:
I've got a WebApplication with a URL to a product like Products?id=123. Let's say I've got an administration page reachable from Products?id=123&editable=true.
If I consider that no one will ever try to enable the editable parameter, and thus don't need any further security mechanism to protect this page, that's security by obscurity, and that's not a good idea, right?
-
In my real case problem, it's slightly more subtle: is there any danger in allowing anyone to know my administration URLS? for instance, while working with XSL, I would like to write:
<xsl:if test="/webAlbums/mode/#admin">
(compute edit link)
</xsl:if>
but wouldn't it be easier for a potential attacker to find a weakness in 'important' pages?
Security through obscurity is barely security at all. Don't count on it.
You should make an authentication system that prevents people from using the admin page through actual security.
As for people knowing your admin URLs, it should be fine as long as your admin page is protected and there is no sensitive data being shown in the URL (such as the internal representation of a data type, the internal ID of some data, etc).
Daniel Miessler gives another element of response in his blog, the one I had in mind when I wrote the question but couldn't formulate:
Obscurity as a Layer makes a system with already good defenses more difficult to target, which improves its overall security posture.
Security Through Obscurity means that, once targeted, the system will be defenseless, i.e. all its security comes from secrecy.
Hiding configuration URLs from unauthenticated clients adds a layer of security, on top of standard authentication mechanisms.
If crackers don't know where the door is, they will be less likely to try to force it!
That's what he does by changing its SSHd port to 24, port scanner will locate the SSH server, but automatic brute-force scripts will only try the default one.
Results? after a weekend, 18,000 attacks on port 22 and 5 on port 24 (he let both ports open to permit the comparison).
You are actually in luck, as what you are proposing is actually not security by obscurity, but actually a perfectly sound security technique called Obscure URL.
To make it work, you need to make sure a part of the URL is as hard to guess as a strong password. It doesn't really matter where you include it, as long as the page cannot be edited unless that part is correct.
Insecure example:
Products?id=123&editable=true
Secure examples:
Products?id=123&editable=true&edit-token=GgSkJSb6pvNT
Products?id=123&edit=GgSkJSb6pvNT
edit/GgSkJSb6pvNT/Products?id=123
GgSkJSb6pvNT/Products?id=123
I don't do web programming, so I may be a bit off-base here, but I think there are a few things to consider:
Just like any other authentication system, if you access the admin page without HTTPS, the page request (which contains the effective "password") is being sent in the clear.
Unless configured to do otherwise, browsers will retain history and cache for the the admin page. This makes the secret URL more available to attackers or even anyone who uses your machine.
As with all passwords, if the secret URL is simple enough, there is a reasonable possibility that it could be brute forced. Something like &editable=true doesn't strike me as secure.
But if handled properly, this should be just as secure as a conventional authentication system.
I have a website registration page, and I'm trying to compile a list of what I need to do to protect it. If you know of an attack, please name it, and briefly describe it preferably with a brief description of its solution. All helpful answers/comments receive an up vote.
Here's what I have in mind so far: (and adding what others are suggesting. Phew, adding other input turned out to be lots of work, but please keep them coming, I'll continue adding here)
SQL injections: from user input date. Solution: prepared statements.
[AviD] "Stored Procedures also provide additional benefits (above prepared statements), such as the ability of least privilege on the DB"
Good point, please explain. I thought stored procedures were THE SAME as prepared statements. What I mean those statements were you bindParam the variables. Are they different?
Not hashing the password before entering into db. Solution: hash passwords.
[AviD] "re Hashing, the password needs a salt (random value added to the password before hashing), to prevent Rainbow Table attacks and same-password attacks."
"the salt used should be different for each user."
Good point, I have a question about this: I know salt should be random but also unique. How do we establish the unique part to counter against the same-password attack? I've been reading on this, but didn't get a clear answer on it yet.
[Inshallah] "if you use a long salt, like 16 chars for SHA-256 ($5$) then you don't really need to verify its uniqueness"
[Inshallah] "Actually, I think it doesn't really matter whether or not there are some conflicts. The salt is only for prevention of table lookups, so even a 2 char salt will be a (small) gain, even if there are conflicts. We are not talking about a cryptographic nonce here that absolutely mustn't repeat. But I'm not a cryptanalyst"
Good point, but does anyone have disclaimers on this point?
Dos attacks?! (I'm guessing this applies to registration forms too)
[Pascal Thivent] "Use HTTPs when submitting sensible data like a password." "for man-in-the-middle attacks, provided that adequate cipher suites are used "
What are the "adequate cipher suites" being referred to here?
[Koosha] "Use HTTPs or encrypt passwords before submition with MD5 and Javascript in clientside."
I don't agree to MD5 and don't like encrypting on client-side, makes no sense at all to me. but other input welcome.
[Dan Atkinson] Exclude certain usernames to prevent clashes with existing pages that have the same name (see original post for full answer and explanation)
[Koosha] "limit allowed characters for username.for example alphabet and numbers, dash(-) and dot(.)"
Please explain exactly why?
[Stu42] "Use Captcha so that a bot cannot automatically create multiple accounts"
[AviD] "There are better solutions than captcha, but for a low-value site it can be good enough."
#AviD, please mention an example?
[rasputin] "use e-mail verification"
[Andrew and epochwolf] xss attacks
Although I don't agree with Andrew and epochwolf to simply filter < and > or to convert < to &tl; and > to >. Most opinions suggest a library like HTMLpurifier. Any input on this?
Use HTTPS, i.e. a combination of HTTP and SSL to provide encryption and secure identification of the server when submitting sensitive data like a password. The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted.
Use recaptcha or asirra to avoid automatic submission. That should stop the bots and script kiddies.
To stop hordes of humans from submitting spam (via mechanical turk or anything like that), log each attempt in memcached and as soon as you reach a maximum submissions from the same IP in a given period of time, block that IP for a few minutes (or hours, days, whatever...).
You should use e-mail verification
and addition to Koosha's answer :
if you let usernames including such chars "#&?/" and create user pages like this site.com/user?me&you/ it may be serious problem in browsers. Please think it in url address bar of browsers.
I guess you should use a salt when hashing the passwords.
Use Captcha so that a bot cannot automatically create multiple accounts
If the routes on your website are set in a particular way (ie, going by the username, rather than their id), then having a username like 'admin' could cause problems. You should probably have an exclude list of possible usernames.
This caused problems in the past with MySpace, and people having usernames like login, and then decorating their page with a phishing form.
Edit:
As has been mentioned in the comments by AviD and Peter Boughton, it is also a way of misleading users. Let's say that a user has the username 'admin'. Then, in their user information page (assuming that they each get one that is available to all, like SO), they have some link in their about section that says like
For more information, visit our dev
blog at mysite.cn/loginpage
Someone maybe sees, 'mysite' in the url, but doesn't really look at the TLD, which would be China (sorry China!), rather than the .com TLD your site is hosted on. So they click through, assuming it's alright (they came from the admin user page after all), and this site looks identical to yours but has a login page. So you 're-enter' your details, but nothing happens. Or it redirects you elsewhere.
This is often the tactic of bank scammers who wish to target customers, inviting them to go to their website to 're-enter a banking password'.
This is just one more form of a type of security known as 'Social Engineering'.
Filter user's data removing '<', '>' - simply html tags. If someone can view user's profile there are possible XSS attacks through data.
Use HTTPS
Use Captcha.
Limit allowed characters for username in server side. for example alphabet and numbers, dash(-) and dot(.).
PS. Clientside encryption is not a secure way. but if you can't use HTTPs, clientside encryption is better than nothing.
Limiting characters, Its a simple way to protect your software from injections(SQL/XSS).
If a user logs into the site, and says 'remember me', we get the unique identifier for the user, encrypt this with RijndaelManaged with a keysize of 256 and place this in a httponly cookie with a set expiration of say.. 120 days, the expiration is refreshed each successful request to the server.
Optionally we generate the initialization vector based upon the user agent and part of the ipv4 address (the last two octets).
Obviously theres no real expiration system built into this, the user could technically use this encrypted key forever (given we don't change the server side key)..
I considered the fact that to allow this feature I need to allow the user to be able to bypass the login and give me their unique id (which is a guid), I figured the guid alone was really hard to guess a real users guid, but would leave the site open to attack by botnots generating guids (I've no idea how realistic it is for them to find a legit guid).. so this is why theres encryption where the server knows the encryption key, and optionally the iv is specific to the browser and ip part.
Should I be considering a different approach where the server issues tickets associated to a user, and these tickets would have a known expiration date so the server stays in control of expiration? should I really care about expiration? remember me is remember me after all?
Looking forward to being humbled ;),
Cheers.
Very similar question.
The solution to your question is in this blog post
"Persistent Login Cookie Best
Practice," describes a relatively
secure approach to implementing the
familiar "Remember Me" option for web
sites. In this article, I propose an
improvement that retains all the
benefits of that approach but also
makes it possible to detect when a
persistent login cookie has been
stolen and used by an attacker.
As Jacco says in the comments: for in depth info about secure authentication read The Definitive Guide To Website Authentication.
Did you consider something like Open Id? As SO uses.
How important is the information that is being remembered? If it's not going to be anything very personal or important, just put a GUID in the cookie.
Including the IP address in the calculation is probably a bad idea, as it would make users using public networks be instantly forgotten.
Using brute force to find GUIDs is ridiculous, as there are 2128 possibilities.