I have a web application, there is one input can let user post their website links.
However I try to protect user as I can.
Is any free website can check the links for you?
What i'm looking for is passing the links to the security site, if the links is ok, it will auto pass to the destination, if not, it will stop and let user know the site is not safe.
links(my site) -> security check website -> destination
The Web of Trust API allows you to check the user-provided "reputation" of a website.
WOT is a good suggestion. However, keep in mind that the crowdsoured nature of this project can be an issue, security wise.
For example, using few fake account, one can boost the trust of a malicious domain. This is especially true for "under the radar" domains, that would generate no organic ratings.
Admittedly, this would probably be resolved over time (as users become exposed to the threat) but the process could be repeated again and again...
I would suggest to use WOT as cross reference, combining it with other factors (i.e. Alexa) just to filter out small domains, which are not likely to be rated - expect by their owners.
Best way is to manage your own list...
Related
I'm possibly developing a web-based application that allows users to create individual pages. I would like users to be able to use their own domains/sub-domains to access the pages.
So far I've considered:
A) Getting users to forward with masking to their pages. Probably the most in-efficient option, as having used this before myself I'm pretty sure it iFrames the page (not entirely sure though).
B) Having the users download certain files, which then make calls to the server for information for their specific account settings via a user key of some sort. The most efficient in my mind at the moment, however, this requires letting users see a fair degree of source code, something I'd rather not do if possible
C) Getting the users to add a C-NAME record to their DNS settings, which is semi in-efficient (most of these users will be used to uploading files via FTP hence why B is the most efficient option), but at the same time means no source code will be seen by them.
The downside is, I have no idea how to implement C or what would be needed.
I got the idea from: http://unbounce.com/features/custom-urls/.
I'm wondering what method of the three I should use to allow custom urls for users, I would prefer to do C, but I have no idea how to implement it (I'm kind of asking how), and whether or not the time spent learning how-to/getting that kind of functionality set-up would even be worth it.
Any answers/opinions/comments would be very much appreciated :)!
Option C is called wildcard DNS: I've linked to a writeup that gives an example of how to do it using Apache. Other web server setups should be able to do this as well: for what you want it is well worth it.
I would like to use eWay (http://eway.com.au) as payment gateway but the problem is it doesn't allow much customization on their hosted page. I would like to display products client would be paying for but that is not possible so I thought maybe just whack hosted page into Iframe. But then again, I'm expecting security issues with it, although couldn't exactly pinpoint what exactly could be the problem. I would be grateful if somone could give me a better idea if it would cause any security holes.
The problem with embedding an iframe from another website that is meant to be secure is that the users have no easy way to check that this website is the one they really want to talk to (your website could quite easily fake that iframe to be on one of your sites without them noticing: you could be the man in the middle, or someone between you and them could, if you're not using HTTPS on your site).
If the iframe points to an HTTPS site (most likely to be the case for payments), the users won't be able to check the lock or blue/green bar.
It's possible to look into the source of the page to check the URI, but very few users know how to do this, even fewer will go that far.
(Note that, even if it's not a good idea, some big websites do this sort of things anyway.)
For the sake of simplicity I want to use admin links like this for a site:
http://sitename.com/somegibberish.php?othergibberish=...
So the actual URL and the parameter would be some completely random string which only I would know.
I know security through obscurity is generally a bad idea, but is it a realistic threat someone can find out the URL? Don't take the employees of the hosting company and eavesdroppers on the line into account, because it is a toy site, not something important and the hosting company doesn't give me secure FTP anyway, so I'm only concerned about normal visitors.
Is there a way of someone finding this URL? It wouldn't be anywhere on the web, so Google won't now it about either. I hope, at least. :)
Any other hole in my scheme which I don't see?
Well, if you could guarantee only you would ever know it, it would work. Unfortunately, even ignoring malicious men in the middle, there are many ways it can leak out...
It will appear in the access logs of your provider, which might end up on Google (and are certainly read by the hosting admins)
It's in your browsing history. Plugins, extensions etc have access to this, and often use upload it elsewhere (i.e. StumbleUpon).
Any proxy servers along the line see it clearly
It could turn up as a Referer to another site
some completely random string
which only I would know.
Sounds like a password to me. :-)
If you're going to have to remember a secret string I would suggest doing usernames and passwords "properly" as HTTP servers will have been written to not leak password information; the same is not true of URLs.
This may only be a toy site but why not practice setting up security properly as it won't matter if you get it wrong. So hopefully, if you do have a site which you need to secure in future you'll have already made all your mistakes.
I know security through obscurity is
generally a very bad idea,
Fixed it for you.
The danger here is that you might get in the habit of "oh, it worked for Toy such-and-such site, so I won't bother implementing real security on this other site."
You would do a disservice to yourself (and any clients/users of your system) if you ignore Kerckhoff's Principle.
That being said, rolling your own security system is a bad idea. Smarter people have already created security libraries in the other major languages, and even smarter people have reviewed and tweaked those libraries. Use them.
It could appear on the web via a "Referer leak". Say your page links to my page at http://entrian.com/, and I publish my web server referer logs on the web. There'll be an entry saying that http://entrian.com/ was accessed from http://sitename.com/somegibberish.php?othergibberish=...
As long as the "login-URL" never posted anywhere, there shouldn't be any way for search engines to find it. And if it's just a small, personal toy-site with no personal or really important content, I see this as a fast and decent-working solution regarding security compared to implementing some form of proper login/authorization system.
If the site is getting a big number of users and lots of content, or simply becomes more than a "toy site", I'd advice you to do it the proper way
I don't know what your toy admin page would display, but keep in mind that when loading external images or linking to somewhere else, your referrer is going to publicize your URL.
If you change http into https, then at least the url will not be visible to anyone sniffing on the network.
(the caveat here is that you also need to consider that very obscure login system can leave interesting traces to be found in the network traces (MITM), somewhere on the site/target for enabling priv.elevation, or on the system you use to log in if that one is no longer secure and some prefer admin login looking no different from a standard user login to avoid that)
You could require that some action be taken # of times and with some number of seconds of delays between the times. After this action,delay,action,delay,action pattern was noticed, the admin interface would become available for login. And the urls used in the interface could be randomized each time with a single use url generated after that pattern. Further, you could only expose this interface through some tunnel and only for a minute on a port encoded by the delays.
If you could do all that in a manner that didn't stand out in the logs, that'd be "clever" but you could also open up new holes by writing all that code and it goes against "keep it simple stupid".
From a usability perspective, is it better to integrate admin section on the main website or have a separate section to manage content?
Any thoughts are greatly appreciated.
EDIT: the application is a CMS for very non-techno friendly staff.
It depends on the project and part you want to administer, imho.
For example comments on newsposts should be administered in the website itself by showing a "delete" linkbutton for each comment. Otherwise the mods would have to look up the comment in the admin section => not very user friendly.
But in general I think a seperate admin section will usually be more clear to your client. You'd want them to see the site as a normal user would see it.
At the very least I would recommend moving all your administration files to a separate folder. That way if you're using a platform like .NET you can very easily control folder access though role and user-based web.config permissions.
Having your administration files all segregated allows you to do other things easily too, like delete them if you decide to move them to another server later. Also you can exclude them in your robots.txt file (although by putting it in the robots.txt file you will be telling other people this section exists, and robots don't have to mind this file).
Edit:
I feel like my answer missed the mark a little considering your question. Of course in-line editing is easier than going to a separate page from a usability perspective, but whenever I hear of mixing admin users with regular users giant alarm bells go off in my head.
I think that it depends on the function of the site and how intrusive it will be to your staff. Does it make sense for them to make changes while browsing the site and will they eventually become discouraged with your system because it forces them to inject unnecessary steps into their process? How long will the edits take? Does it make sense to show a completely different interface to administrators? I think an answer to this question requires a lot more understanding of what specific function you're trying to accomplish and will vary on a case by case basis.
I have never liked adding administration pages into the main site. It seems like it is too much of a risk from someone accidently getting access to the administration portion of the site. Even if you review the security over and over, there is always that possibility that something unexpected will happen, and it is a huge mess to clean up (what was modified, who accessed what etc. etc.). In my opinion keeping it as a seperate site is the easiest way to go.
While there is a level of convenience in being able to login to the main part of a site as a privileged user, and then clicking on parts of a page to edit/alter it, there is also a measure of security in having it in a separate area.
I have found that having a separate section of the website that is devoted specifically to administrative tasks makes the tasks easier to organize and use. Just look at Wordpress (especially the new 2.7 release), Drupal (a very popular cms), and Joomla (another very popular cms). If you would like to test these feature out to see why I think the separate section is better, you can go to www.opensourcecms.com and test out both Drupal and Joomla.
From a usability, the more integrated the better but it tends to add severely to the complexity. Its always best if you can perform the action within the context in which it occurs - lock out a bad user, trim a log thats too big etc. however since these tend to have significant side effects the security aspect trumps this a lot of the time out of fear.
I think you need to look at doing a risk assessment with regards to integrating the administration capabilities right into the application.
What would be the implication for the system if someone were able to escalate privelages and gain access to the admin functions. if every user was locked out maliciously - damage to the site, the reputation, SLA etc?
What destructive functions can an admin perform from this section ? delete lots of data? crash the app? alter costs that have material impact on users/customers?
Are the admin functions integrated in the app or isolated into specific admin functions?
Does the application have a public face or is it an intranet that is assumed secure?
I personally have never felt at ease integrating the admin section with the site out of fear that a security breach caused by my ineptness or something beyond my control like bad defaults, unpatched exploit. However, when the client is writing the cheque I tend to do what they feel is best.
I come from the school of Usability that says "minimise guess work". So, what kind of information did you get from your user group sessions?
Remember, you're not (and we're not) typical users of your system. Anything we say is going to be a guess. What's worse is that any opinion shown here is likely to be ill informed for your situation (but probably awesome at what they do). The only way you'll have an informed opinion on what to do is by going out and asking your users in intelligent ways.
Because this is a security issue some of your user mix should be people who specialise in security. Just because it's easier to use doesn't mean it's the most appropriate.
What is your suggested solution for the threat of website UI spoofing?
By definition any solution that relies on the site showing you personalised information once you've logged in is ineffective against phishers. If you've attempted to login, they've already succeeded!
FWIW, I don't yet know the real answer, maybe this question will throw up some good ideas. I am however professionally involved in research into phishing, bad domain registrations, etc.
I don't believe there's any significant technical solution that web site developers can implement. Again, by definition, if your users arrive at a phishing site you're no longer in control.
This is why all current anti-phishing technologies reside in the browser, and not in the phished site.
The key to this problem is identifying some difference between a request to the real site and a request to the spoof site.
The simplest difference is some cookie-based UI preference. A cookie set on your (real) site will only ever be returned to your site, and will never be sent to a spoof site.
Now there are plenty of reasons that the valid cookie might not be sent to your site, the user might be using a different computer or they might have expired/deleted cookies, but at least you can guarantee that it won't be sent to the spoof site.
I think the only answer here is to program better people.
Doing things like customizing the appearance or uploading an image only work if the user in questions actually recognizes when these things are wrong. I think the majority of users would never recognize these things except for sites they visit a lot. Even if they did they may attribute it to a change in website design and not a phish.
One solution is to customize the web site per user. Spoofing only works when users have basically the same view of the website (one spoof - many victims). So if, for example, eBay would let you configure a custom background color, you should be able to notice that the page you're viewing is some spoof (that won't know your choice of color). A real solution is a bit more complex (like maybe a secret keyword configured in the browser that only the browser can render within password controls or into the url bar, etc.), but the idea is the same.
Customize the UI per user so spoofing (which relies on most users expecting to see basically the same UI) stops working. It can be a browser based solution, or something web sites offer to their users (some already do).
I've seen some sites that let you select a "personal" icon. Whenever you log in, that icon is displayed as proof that you are on their site.
You can ask a question when the user login (a question that the user has written with the answer).
You can display a picture after the loggin that the user have uploaded, if the user doesn't see his picture (private that only him could see) than it's not the real website.