I'm assuming you are part of APEWS since you pretty much recited verbatim what's in their rather useless FAQ?
While they may run spamtraps, it has already been proven by SANS that they DO COLLECT DATA from other sources and use that to construct their blocklists. I would go read the SANS diary post. You can not defend them by claiming they use only spam traps when it has been proven they do not.
If (and that's a big if) someone on an MCI data circuit (or any hot for that matter) was the problem, there is nothing stopping APEWS from listing only the IP block registered to the offender, as that info is readily available from ARIN. To list the entire MCI block, comprised of thousands of companies, is beyond stupid. As SANS pointed out, they are also listing the entire AT&T network. They took a/32 listings SANS had at http://isc.incidents.org/ipsascii.html and rolled it up to/17s. You think blocking 32,000 hosts in responce to a single IP address being listed somewhere else is helping anything?
MCI is not the problem, as you say. APEWS and people who rely on it are the problem. The list is not the least bit accurate and whoever runs it doesn't seem to want to take responsibility for their bad practices. It's garbage, period.
I actually sent some feedback to SANS when I saw the problems they were having with these idiots and told them about my experiences with them (I'm sure I wasn't the only one)
My company has been getting some bounceback emails from certain clients who rely too heavily on this blacklist. I go to their site and find out that not only are listing my companies network, but a large portion of MCI's commercial data circuits as well. It appears they simply gather these entries from other sources and then increase the scope of the listing to include a stupidly large number of IPs (mainly the entire upstream provider). As SANS noted, they were blocking just about the entire AT&T network. They don't identify who they are, they have no method of being contacted, and they are incredibly careless. Anyone who relies on an APEWS or SPEWS blocklist for anything will be very sorry they did. They are beyond useless. There are some reputable blocklists that, when used correctly and with a combinatino of other filtering methods, can provide positive results. These idiots are not among that group.
No, I meant exactly what I said. "Texts" meaning books and documentation written on VB.NET and ASP.NET, I'm assuming you missed that word? The platform itself can be quite secure if used correctly. The problem, however, is that the materials used to teach developers, ranging from Microsoft itself to 3rd party books to blogs, often demonstrate the simple solution rather than the secure one.
Microsoft VB.NET and ASP.NET texts are AWFUL in this regard. Nearly all examples use in-line SQL queries rather than paramaterized stored procedures. Why? Probably because they are trying to fit in with Microsoft's strategy that devoping applications should require absolutely no knowledge of code (or anything else for that matter). The big selling point for their VS 2005 suite is "no code required". That speaks volume.
Agreed. This alone can prevent the majority of SQL injection attacks. For some stupid reason, though, most RAD applications do NOT do this. Even worse, as you point out, is that many textbooks and online articles give examples using in-line SQL statements.
This problem will not go away until both software companies and employers move to a Secure Application Development mentality rather than a RAD mentality. Developers who know only point and click tools with no knowledge of code simply can not build secure applications. When industry realizes they are better off paying the extra cash to have things done right by knowledgeable developters, this trend of unsecure web applications will start to reverse itself.
Slashdot Mirror
I'm assuming you are part of APEWS since you pretty much recited verbatim what's in their rather useless FAQ? While they may run spamtraps, it has already been proven by SANS that they DO COLLECT DATA from other sources and use that to construct their blocklists. I would go read the SANS diary post. You can not defend them by claiming they use only spam traps when it has been proven they do not. If (and that's a big if) someone on an MCI data circuit (or any hot for that matter) was the problem, there is nothing stopping APEWS from listing only the IP block registered to the offender, as that info is readily available from ARIN. To list the entire MCI block, comprised of thousands of companies, is beyond stupid. As SANS pointed out, they are also listing the entire AT&T network. They took a /32 listings SANS had at http://isc.incidents.org/ipsascii.html and rolled it up to /17s. You think blocking 32,000 hosts in responce to a single IP address being listed somewhere else is helping anything?
MCI is not the problem, as you say. APEWS and people who rely on it are the problem. The list is not the least bit accurate and whoever runs it doesn't seem to want to take responsibility for their bad practices. It's garbage, period.
My company has been getting some bounceback emails from certain clients who rely too heavily on this blacklist. I go to their site and find out that not only are listing my companies network, but a large portion of MCI's commercial data circuits as well. It appears they simply gather these entries from other sources and then increase the scope of the listing to include a stupidly large number of IPs (mainly the entire upstream provider). As SANS noted, they were blocking just about the entire AT&T network. They don't identify who they are, they have no method of being contacted, and they are incredibly careless. Anyone who relies on an APEWS or SPEWS blocklist for anything will be very sorry they did. They are beyond useless. There are some reputable blocklists that, when used correctly and with a combinatino of other filtering methods, can provide positive results. These idiots are not among that group.
No, I meant exactly what I said. "Texts" meaning books and documentation written on VB.NET and ASP.NET, I'm assuming you missed that word? The platform itself can be quite secure if used correctly. The problem, however, is that the materials used to teach developers, ranging from Microsoft itself to 3rd party books to blogs, often demonstrate the simple solution rather than the secure one.
Microsoft VB.NET and ASP.NET texts are AWFUL in this regard. Nearly all examples use in-line SQL queries rather than paramaterized stored procedures. Why? Probably because they are trying to fit in with Microsoft's strategy that devoping applications should require absolutely no knowledge of code (or anything else for that matter). The big selling point for their VS 2005 suite is "no code required". That speaks volume.
Agreed. This alone can prevent the majority of SQL injection attacks. For some stupid reason, though, most RAD applications do NOT do this. Even worse, as you point out, is that many textbooks and online articles give examples using in-line SQL statements. This problem will not go away until both software companies and employers move to a Secure Application Development mentality rather than a RAD mentality. Developers who know only point and click tools with no knowledge of code simply can not build secure applications. When industry realizes they are better off paying the extra cash to have things done right by knowledgeable developters, this trend of unsecure web applications will start to reverse itself.