My server has links to other servers. I have a relationship with the managers of those servers. I want to be sure that links to PDF files make the client Browser prompt the user to SAVE the file, not to have the file open directly in the Web browser. I don't believe I need to change the HTTP Headers on my server, I need to ask the admins on the associated servers to change THEIR HTTP headers to "allow cross origin" when they receive requests from my site as the "referrer". Is this correct? It's not easy to get this answer, lots of examples to this type of query talk about "go to your Browser settings and change how PDFs are handled", but I need a solution that, apart from users who HAVE set their Browser as their OS default PDF viewer, the PDF files will download to be opened in a sophisticated and powerful PDF renderer.
Tried some experiments on two servers I have direct control over, it seemed to work, but now need to engage with other server admins and I want to be sure I'm asking them to alter their HTTP config header without bothering them excessively: I don't want to have to do a lot of "experiments" with them, I want to be confident that what I'm asking them to do or change is correct.
Related
Using MS Edge and apache w/ php, I just discovered via access.log that when I have the JavaScript debug panel (i.e. developer panel) open, it is making every http call twice. When I closed this panel, it has fixed the issue of all insert statements getting called twice.
Question: Does this doubling of http calls happen on every / most browsers that I need to look out for, or is this something special/unique with MS Edge?
I can't speak for all browsers and all developer tools. But, for IE and Edge the first time you open the tools and then open a JS file in the sources view it will try to request the file again. That request will be served from the local browser cache, sometimes not, depending on the cache settings for the file being requested.
The reason browser tools need to make this request is that browsers will often throw out the original source file as it doesn't need it to execute the page, as the source has been parsed it into something else that it can work with.
However, after you've opened the developer tools the browser will keep around sources in future navigations, either in the tools front end or elsewhere. Not keeping sources is an optimization for the first time use case, to save browsers keeping around source on the very low odds of the tool being used on any given navigation.
Of course some files are never cached by the browser and will need to be downloaded when requested by the tools, for example sourcemapped files.
In general any resources on your site that can be accessed by HTTP GET should be idempotent. That is, a GET shouldn't change the resource being requested (or generall the state of your site), so hopefully making additional requests shouldn't be an issue.
My server has been compromised recently. This morning, I have discovered that the intruder is injecting an iframe into each of my HTML pages. After testing, I have found out that the way he does that is by getting Apache (?) to replace every instance of
<body>
by
<iframe link to malware></iframe></body>
For example if I browse a file residing on the server consisting of:
</body>
</body>
Then my browser sees a file consisting of:
<iframe link to malware></iframe></body>
<iframe link to malware></iframe></body>
I have immediately stopped Apache to protect my visitors, but so far I have not been able to find what the intruder has changed on the server to perform the attack. I presume he has modified an Apache config file, but I have no idea which one. In particular, I have looked for recently modified files by time-stamp, but did not find anything noteworthy.
Thanks for any help.
Tuan.
PS: I am in the process of rebuilding a new server from scratch, but in the while, I would like to keep the old one running, since this is a business site.
I don't know the details of your compromised server. While this is a fairly standard drive-by attack against Apache that you can, ideally, resolve by rolling back to a previous version of your web content and server configuration (if you have a colo, contact the technical team responsible for your backups), let's presume you're entirely on your own and need to fix the problem yourself.
Pulling from StopBadware.org's documentation on the most common drive-by scenarios and resolution cases:
Malicious scripts
Malicious scripts are often used to redirect site visitors to a
different website and/or load badware from another source. These
scripts will often be injected by an attacker into the content of your
web pages, or sometimes into other files on your server, such as
images and PDFs. Sometimes, instead of injecting the entire script
into your web pages, the attacker will only inject a pointer to a .js
or other file that the attacker saves in a directory on your web
server.
Many malicious scripts use obfuscation to make them more difficult for
anti-virus scanners to detect:
Some malicious scripts use names that look like they’re coming from
legitimate sites (note the misspelling of “analytics”):
.htaccess redirects
The Apache web server, which is used by many hosting providers, uses a
hidden server file called .htaccess to configure certain access
settings for directories on the website. Attackers will sometimes
modify an existing .htaccess file on your web server or upload new
.htaccess files to your web server containing instructions to redirect
users to other websites, often ones that lead to badware downloads or
fraudulent product sales.
Hidden iframes
An iframe is a section of a web page that loads content from another
page or site. Attackers will often inject malicious iframes into a web
page or other file on your server. Often, these iframes will be
configured so they don’t show up on the web page when someone visits
the page, but the malicious content they are loading will still load,
hidden from the visitor’s view.
How to look for it
If your site was reported as a badware site by Google, you can use
Google’s Webmaster Tools to get more information about what was
detected. This includes a sampling of pages on which the badware was
detected and, using a Labs feature, possibly even a sample of the bad
code that was found on your site. Certain information can also be
found on the Google Diagnostics page, which can be found by replacing
example.com in the following URL with your own site’s URL:
www.google.com/safebrowsing/diagnostic?site=example.com
There exist several free and paid website scanning services on the
Internet that can help you zero in on specific badware on your site.
There are also tools that you can use on your web server and/or on a
downloaded copy of the files from your website to search for specific
text. StopBadware does not list or recommend such services, but the
volunteers in our online community will be glad to point you to their
favorites.
In short, use the stock-standard tools and scanners provided by Google first. If the threat can't otherwise be identified, you'll need to backpath through the code of your CMS, Apache configuration, SQL setup, and remaining content of your website to determine where you were compromised and what the right remediation steps should be.
Best of luck handling your issue!
How would I let a running process know that a context menu has been clicked in Safari?
I've read that this is not possible due to security, but that seems wrong because 1Password somehow pulls all of the information from the desktop app's database into the Safari extension. I wrote the extension to display the context menu and was trying to send an XMLRPC request to localhost, but couldn't get it to work.
I'm not certain of this, but I think 1Password does what it does by having a background process (1PasswordAgent) constantly polling for certain changes in the extension's local database and/or config files. For example, to initially get your passwords into the extension, the extension could set a certain flag in its localStorage db, which would get written (by Safari, not by the extension) to a file. The agent would then notice the flag in the file and copy your passwords from the main 1Password database into the extension's local database. Similarly, when the extension creates a new password entry, the agent would notice the change in the extension's database and mirror it to the 1Password database.
Perhaps you could do something similar?
Although I have no idea about the implementation of 1Password, LiveReload achieves the same by using WebSocket to connect to a localhost URL (handled by the application). If you do it from the global page, cross-domain limitations do not apply, so you are free to connect to any URL:
var ws = new WebSocket("ws://localhost:98765");
...
(Be careful with that localhost thing, though, Chrome on Linux wants 0.0.0.0 instead of 127.0.0.1 or localhost. At least it used to want it.)
I'm wondering how I can find out where the culprit is, as to what is NOT being transmitted over SSL on my website. It's blowing my mind, because I use relative URLs or explicitly choose HTTPS:// for all links, images, etc...
Any ideas/tools to find out what the issue is?
Thanks.
If you mean that some resources are transferred over HTTP without encryption, you can check for this in Chrome's Developer tools in the tab Resources - that should tell you which parts come from where - look for those with address starting with http:// .
Alternately, use Fiddler: by default, it won't decrypt HTTPS connections, so you'll be seeing CONNECT requests for HTTPS, and GET/POST for HTTP - those are your culprits.
For those, like myself, who run into this issue i suggest a few tips while designing your website.
Always use relative paths when ever possible "images/someimage.png" instead of using domain paths like http://someDomainName/images/someimage.png so on. Any one of these and it will cause the browser to throw that warning at you.
When linking to external content, Google/other Ads, javascript sources(such as jquery, so on), or any other media... make sure you use a https:// link if they have one available. Myself, i had one tiny image for a link to an external site but they did not offer a https link to the image, so i simply downloaded it and put it in my images folder. Problem solved.
The Chrome resources list is a very helpful tool, not sure if Firefox has something similar in its tool box. Another method, if you have shell/command line access, is to use grep to search the files for "http:". This, most often, will show anything that is linking to non secure content.
Certain directories are protected by Basic Auth using a .htaccess file on an older Apache 1.x server. Today a user pointed out that the username/password was requested twice for the file he had just posted - once when entering the directory to see the index, and then AGAIN when downloading the file. Finding this odd, I researched the usual problems with double-firing .htaccess authentication:
server name (http://server vs. http://www.server)
trailing slash (http://server/somedir vs. http://server/somedir/)
http vs https
No luck. Add to the confusion that Firefox/Chrome/Safari don't ask twice - only IE (6 and 7). Further investigation showed that this doesn't happen with PDF files - only Excel files - even blank ones.
Is Excel calling back to the server somehow that requires a second authentication? Why does it only happen in IE?
Not critical - but I'm very curious what could be causing this.
EDIT - I think bmdhacks nailed it. Watching the network traffic, Excel+IE fires back a second request with a different User Agent called "Microsoft Protocol Discovery"
I'm not sure about Excel, but Windows Media Player has a special interaction with IE where when IE requests a file with a MIME type that Windows Media Player owns, instead of handing the downloaded file over to WMP, it instructs Windows Media Player to download the file itself. This could result in requesting the file twice, once for IE to ask for the file, and a second time when WMP downloads it.
It's possible that Microsoft uses this mechanism in other products like Excel too. You might be able to discover this by looking at the User-Agent header submitted in the second request. In the Windows Media case, it actually changes from IE to WMP's User-Agent on the second request.