In order to verify that I own a website, google asked me to do the following:
Download this HTML verification file. [googleXXX.html]
Upload the file to http://www.example.com/
Confirm successful upload by visiting http://www.example.com/googleXXX.html in your browser.
Click Verify below.
To stay verified, don't remove the HTML file, even after verification succeeds.
The file provided by google contains a single line:
google-site-verification: googleXXX.html
How that this work? How is that supposed to tell them that I actually own that domain?
It doesn't tell them that you own it, it tells them that you have write permission to it. That's considered enough.
It demonstrates that you have sufficient control of the web server at the domain to be able to add pages to the website. The assumption is that this level of control would only be available to the owner of the domain, or a delegated administrator.
Related
In the past, I've used NGINX and the ngx_http_secure_link_module to achieve this, which has worked great. If you try to access a media file directly, you get a 403 access denied error. But with a valid signed URL...
emample.com/media/audio.mp3?expires=[1 hour]&signature=[SHA2(filename+expiration+secret)]
...access is granted.
But I'm using IIS now, and I'm wanting to achieve the same thing. I've tried using ASP code with the URL rewrite module, where I'd create an empty media folder with an ASP page to process requests, store all media in an offline folder, and use the rewrite module to spoof URLs.
For example...
emample.com/media/audio.mp3?expires=[1 hour]&signature=[SHA2(filename+expiration+secret)]
...would rewrite to a page called "stream.asp". I'd check the signature, return an error if it was incorrect, but otherwise I'd change the content type property to match that of the file, then do a binary stream from the offline folder where the real file is stored.
This worked fine for documents, but for audio and video, it was sluggish, and you couldn't skip the content back and forth. I'm sure I could have adjusted the code to have made this possible, but accessing files this way put a lot of strain on IIS.
What I'm looking for is a simple URL check in IIS that either grants access to a file or denies it based on a URL signature check.
Does anybody know of an IIS module that can do this? Or perhaps it's even possible to use the URL Rewrite module to achieve this?
I am not asking how. I am asking if. Is it possible to bypass a 403 error on the web?
Let me explain a bit in detail. On a web server the IIS has set up a directory for a project we are such that it is not accessable to the outside. So if you type the path to that directory in a web browser, the web browser will say that it is not accessable and it will throw a 403 error.
Now, here is the problem. Some files are placed there with some secure information. A programmer on our team has made a big deal about this and the fact that the files are placed on a server that is accessalbe to the outside world. On the other hand, I think this is not such a big deal since if a user on the outside tried to go to that directory, his web browser will throw the 403 error. But other people on the team say that a hacker can still somehow access it.
So that leads me here and to my question. Is it possible to bypass a 403 error on the web? I say no. Some network guys at work say maybe. I am not asking how to do it. I am only asking if it is really possible.
I gather from your information that there is a web server with a directory setup on the web like so
http://www.example.com/directory
Now, if you navigate to this URL you get a 403 Forbidden error? However, if you know the name of a file you can go to http://www.example.com/directory/MyImportantDocument.docx and it is possible to view the document at this location?
Unless there is a runnable script on your server that does this, it is not possible to view the directory contents via the web. However, URLs are not considered secure as they are logged in browser history, proxy and server logs and can also be leaked by browsers' referer header. I assume the files are stored here so they can be accessed by a remote application?
File names can be easily brute forced by an attacker. Tools such as dirbuster and dirb do this automatically. Therefore, if the files do not need to be readable remotely, they should be moved to an internal server, not accessible from the internet or DMZ.
If access is needed you should implement some sort of authentication. At the very least activate basic auth on IIS. This will prompt a web browser user for a username and password in order to view files, or the files can be accessed programmatically by setting the appropriate Authorization header, which is an encoded username and password.
Better would be something with comprehensive session management, like an application pre-built for this purpose. E.g. a CMS which is kept up-to-date and securely configured.
Also you should make sure that the IIS website is only configured to be accessed via HTTPS which will protect against traffic snooping of the credentials, URL path, headers and file contents.
In some cases (e.g. Back-end or web server mis-configuration) it's possible to bypass 403. For understanding those methods read this script:
https://github.com/lobuhi/byp4xx
this script contained well-known methods and collected from various bug bounty communities.
So if your back-end server not vulnerable to this script, probably it's safe.
So basically it is NOT possible if the server software itself doesn't has any bug. But if you have other parts of your website that are public and probably using a dynamic scripting language that may higher your risk if someone is able to find a hole with something like "access file from filesystem".
In general I would recommend you to NOT store any security relevant files on a public server that don't need to!
If you could avoid it, it's always the better way.
There is a simple exploit to bypass .httacess restrictions... Try to Google "bypass error 403" and you will find the method. As auditor I can confirm that it is not a good practice (and if I see it I will always raise it as an issue) if you store credentials (or any other sensitive information) in plain text on web server.
Let's say there's a website www.example.com/user/john. Accessing that link takes you to www.example.com/user/john/index.html.
There are files like www.example.com/user/john/picture.png and www.example.com/user/john/document.html. These are also accessible to the public, but there's no link to these from index.html.
Is there a systematic way to find out these files? I'm asking because I'm going to set up my website, and I also want to put up a few files that I don't necessarily want every one to see, only people who I give the link to. So I'm wondering how easy/hard it is to find out that those files exist in my directory.
Most importantly you have to switch off the possibility to just browse the directory with the browser. Every server has its own way to switch this off. Then you can use the proposed way of "security through obscurity".
Another way can be, to have a specific folder whos access is restricted by a http basic authentication. This can be configured in the .htaccess file which you put in the root folder of your directory you want to share only with specific people.
Just google ".htacces" and "basic authentication".
HTTP does not provide a directory listing method as such. Most web servers can be set up to provide a HTML-formatted directory listing if an index file such as index.html does not exist. If you provide an index file so that autoindexing does not happen (or if you disable autoindex by web server configuration), and if your "hidden" file names are hard to guess, they should be pretty hard to find. I sometimes publish such files in a directory with a random gibberish name.
"Share links" used by Dropbox, Picasa and other services do the same, they just use longer random file/directory names or random parameters in the URL.
To provide real security you'll want to set up https (SSL/TLS) so that any eavesdroppers on the network cannot easily look at the requested URLs, and authentication such as HTTP Basic Authentication with username/password. For less sensitive stuff, http to a random hidden directory will often do fine.
I am starting to create a site that uses Drupal. One of my requirements is that nobody will see any "real" content until they log in. The home page will basically be a static page with a logo, some basic "this is what the site does" copy, and then a login form. If you don't login, you can then only see some other static pages (faq, legal, privacy, etc...) but you can't use the actual site. Think Facebook's login page, basically just fluff with a login form.
From searching around, I have found 3 different methods for this:
Create a page that is basically separate from the Drupal installation, but then when the form submits, check it against the Drupal DB and then proceed if logged in successfully. This would be done with Apache, maybe an .htaccess file directive to change the first served page.
Use the Front Page extension. I haven't looked at this too extensively, has anyone used it? Pros/Cons?
Somehow finagle the default Druapl "Home Page" functionality to allow this to happen. I would rather not have to do this, unless someone knows that there is an easy way to do this.
One of my requirements is that nobody will see any "real" content until they log in.
There is a permission that users need have in order to access content on Drupal (access content); if anonymous users don't have that permission, then they would not be able to see any content.
Using the module you reported, you can create a different home page for anonymous users.
Solution #1 is not the ideal one as it requires more work for something that can be obtained from inside Drupal. Take in mind that the correct way to access Drupal DB is to use the DB API Drupal comes with.
I've got a section on my site which allows users to upload a link in their profile, to their MySpace account. In order to secure other users, I want to to hard code the domain name (www.myspace.com/) and append the user's (sanitized) input. To me, this seems pretty secure and ensures that it always goes to MySpace.com. However, is there any way a malicious user can append a tag to the end "www.myspace.com" which redirects it to another site? Or, since the domain name is hardcoded, anything added after that will simply lead to a 404 error?
Thanks
Firstly, you must sanitize the input (as you note). Assuming you do, then if the domain is hardcoded, the link will go to the servers at myspace.com, and it's up to myspace.com to do the right thing with possibly bad input. But it will not be hijacked to another domain.
If you don't sanitize, a user could enter something like
myname" onclick="do_evil_stuff...">...
and that could hijack the link.