Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Serious Problem I NEED HELP 4
- Thread starter brantGuy
- Start date
- Thread starter
- #21
Working now yeah, ran a test and I'm assuming the table is still there, as your system caught what i tried.
The best way to test this would be to put the bits live again that kept disappearing. If they stay there, job done, sounds like it has been sorted, if they go again then come abck and we'll look into some more. As you are on a shared server someone might be using some of the cfadmin api functions to play around with things.
something else we could try is to remove some of the priviliges from the datasource. I think that drop is an option, but you would need to get your host admin person to do that. the option is under the datasource and then advanced options
Hope this helps!
Tony
The best way to test this would be to put the bits live again that kept disappearing. If they stay there, job done, sounds like it has been sorted, if they go again then come abck and we'll look into some more. As you are on a shared server someone might be using some of the cfadmin api functions to play around with things.
something else we could try is to remove some of the priviliges from the datasource. I think that drop is an option, but you would need to get your host admin person to do that. the option is under the datasource and then advanced options
Hope this helps!
Tony
- Thread starter
- #23
- Thread starter
- #24
imstillatwork
IS-IT--Management
After years of crying CFQUERYPARAM to everyone with DB problems a real life situation comes up and Sarky78 beats me too it 
This should really drive home the point of how serious the matter is though! There are 1000's and 1000's of CFML, PHP, ASP applications out there that are vulnerable to this sort of thing. At least CFML makes it easy to prevent.
I have been in the habit of use CFQP always - any query that use a CF variable.
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
This should really drive home the point of how serious the matter is though! There are 1000's and 1000's of CFML, PHP, ASP applications out there that are vulnerable to this sort of thing. At least CFML makes it easy to prevent.
I have been in the habit of use CFQP always - any query that use a CF variable.
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
- Thread starter
- #27
Im now a convert...Praise the lord....
I have a website, huge website, there is probably close to 500 querys made through the entire site...both front and back end...
But there is one thing I dont understand...
If I have a cftextarea as my site does and the sql is set to ntext ..how does chqueryparam prevent the drop table...
Craig
I have a website, huge website, there is probably close to 500 querys made through the entire site...both front and back end...
But there is one thing I dont understand...
If I have a cftextarea as my site does and the sql is set to ntext ..how does chqueryparam prevent the drop table...
Craig
imstillatwork
IS-IT--Management
you might specify something like
insert into mytable(textfield)values('#form.text#')
which might end up looking like
insert into mytable(textfield)values('hello, this is text')
Someone clever can enter text that causes that form.text value to mess with the way the query runs, and IN MSSQL, end that sql statement and run another - called SLQ injection.
CFQUERYPARAM will bind the variables (ex: form.text) to SQL data types so that no matter what the value of it is, it is ALWAYS rendered as just a string (or integer, or whatever) and NEVER as executable SQL. this is a 'prepared statement' which has several benefits also, usually including speed.
A prepared statement is sent to the SQL server when cfqueryparam is used. Do research on prepared statements for more info.
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
insert into mytable(textfield)values('#form.text#')
which might end up looking like
insert into mytable(textfield)values('hello, this is text')
Someone clever can enter text that causes that form.text value to mess with the way the query runs, and IN MSSQL, end that sql statement and run another - called SLQ injection.
CFQUERYPARAM will bind the variables (ex: form.text) to SQL data types so that no matter what the value of it is, it is ALWAYS rendered as just a string (or integer, or whatever) and NEVER as executable SQL. this is a 'prepared statement' which has several benefits also, usually including speed.
A prepared statement is sent to the SQL server when cfqueryparam is used. Do research on prepared statements for more info.
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
Just to carry on from what Kevin has said. If you are looking for real security and speed then you should really look at stored procedures instead of using embedded queries. cfqueryparams will provide the data binding and some security, but they have to be compiled everytime they are executed. With a stored procedure you get the data binding, the security but also the spppppeeeeedddd!!
Hope this helps!
Tony
P.S Kevin....sorry for beating you to the cfqueryparam soap box!
Hope this helps!
Tony
P.S Kevin....sorry for beating you to the cfqueryparam soap box!
imstillatwork
IS-IT--Management
SP's can also do a lot more technical things that embedded queries won't do so well. alot of our slow pages with lots of cf processing query results can be done as a stored procedure waymorefaster-er.
General rule: If SQL can do it, do it with SQL!
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
General rule: If SQL can do it, do it with SQL!
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
- Thread starter
- #31
stevelionbird
Programmer
I agree with Kevin on using stored procedures .. I use them a lot.
[twoCents]
However, even at a point where I am all warm and fuzzy writing them, they can be cumbersome to debug (at least in MySQL 5)
Well worth the effort when it's a heavily used query and they're immune to them injections
[/twoCents]
-Steve
[twoCents]
However, even at a point where I am all warm and fuzzy writing them, they can be cumbersome to debug (at least in MySQL 5)
Well worth the effort when it's a heavily used query and they're immune to them injections
[/twoCents]
-Steve
a stored proc for your guestbook insert would look something like this:
then the invoke would be something like this:
you can put whatever processing you need before the sp invoke, and pass whatever params you want to it, using whatever scope you want
Hope this helps!
Tony
Code:
create procedure sp_insertGuestBook
i_name varchar(30),
i_hometown varchar(30),
i_email varchar(100),
i_message varchar(3000),
i_ipAddress integer,
i_display varchar(3),
as
INSERT into guestbook
(name, hometown, email, message, ipAddress, dateposted, display)
VALUES (@i_name, @i_hometown, @i_email, @i_message, @i_ipAddress, getDate(), @i_display);then the invoke would be something like this:
Code:
<cfstoredproc datasource=="#DSN#" procedure="sp_insertGuestBook">
<cfprocparam cfsqltype="cf_sql_varchar" value="#form.name#" type="in">
<cfprocparam cfsqltype="cf_sql_varchar" value="#form.hometown#" type="in">
<cfprocparam cfsqltype="cf_sql_varchar" value="#form.email#" type="in">
<!--- and so on --->
</cfstoredproc>you can put whatever processing you need before the sp invoke, and pass whatever params you want to it, using whatever scope you want
Hope this helps!
Tony
-
1
- #34
These are some of my security notes - hacked from various sources:
SQL Injection
Use URLEncrypt and URLDecrypt from
For Form fields, use a Checksum field
Calling page:
<input type="hidden" name="ID" value ="#GetBouquets.BouquetID#">
<input type="hidden" name ="checksum" value ="#hash(GetBouquets.BouquetID)#">
In the submit page:
<CFIF hash(FORM.ID) neq FORM.checksum>
Bad Form
<CFABORT>
</CFIF>
The hash() function gives a check sum for a string so if the string is changed, the hash of it will change too. For multiple hidden fields first combine them into one string, then hash that. It doesn't matter how long the string is, the hash function always returns 32 characters.
Validate all URL and FORM parameters with the CFPARAM tag. To make sure that a URL parameter is supplied, leave out the DEFAULT parameter of CFPARAM and an error will be thrown if the URL variable is missing.
Use CFPARAM
One way hackers can hurt your site is by running bad SQL in your queries by typing the extra SQL into URL or FORM parameters that you use in your CFQUERY statements.
A little-known feature of SQL Server is that you can run two SQL statements from one CFQUERY by separating them with a semicolon. Hackers exploit this by injecting extra SQL via URL parameters. For example, suppose you have a CFQUERY in page.cfm that contains the following SQL:
SELECT * FROM EMP WHERE ID = #URL.USER ID#
And normally the page is run like this:
ID=7
This will cause the following SQL to be run in your CFQUERY:
SELECT * FROM EMP WHERE ID=7
Now the hacker adds extra SQL commands on the end of the URL variable (the %3B and %20 encode a semicolon and a space, respectively, in a URL string):
ID=7%3BDELETE%20FROM%20CustomerTable
This will cause the following SQL to be run in your CFQUERY:
SELECT * FROM EMP WHERE ID=7 ;DELETE FROM CustomerTable
This will run both SQL commands and delete all your records from the table CustomerTable.
Other attacks use the vertical bar character (|) to run VBA functions in Access. One of the most dangerous VBA functions is shell(), which will run any command string in a shell on your server. Just think what a FORMAT command might do to your server.
In SQL Server the similar xp_cmdshell function is equally dangerous and can be turned off in the SQL Server admin.
To prevent SQL injection hacking, use <CFQUERYPARAM> on all SQL parameters.
A side benefit of using CFQUERYPARAM is that your queries will run faster because SQL Server or Oracle will be more likely to use a cached query plan instead of recalculating the query plan from scratch.
Note: Some programmers use the ColdFusion val() function to protect numeric parameters, but CFQUERYPARAM also works with other datatypes and - unlike val - it generates an error when the data type is incorrect. Also, the previous tips on removing dangerous characters and encrypting URL variables help to prevent SQL injection attacks, but these should be used only in addition to CFQUERYPARAM, and not instead of it.
<CFPARAM NAME = "somename" DEFAULT="something" TYPE="UUID STRUCT STRING QUERY NUMBERIC DATE BOOLEAN BINARY ARRAY>
<cfquery name="EmpList" datasource="CompanyInfo">SELECT * FROM Employee WHERE Emp_ID = <cfqueryparam value = "#Emp_ID#" cfsqltype = "cf_sql_integer">
</cfquery>
Mask Error Handling
Create Error Handler - add CFERROR tags application.cfm
<CFERROR TYPE="REQUEST" TEMPLATE="Other/Error1.cfm">
<CFERROR TYPE="Exception" TEMPLATE="Other/Error3Email.cfm">
<CFMAIL
FROM="webmaster@precorp.coop"
TO="shaneh@precorp.coop"
SUBJECT="Error Report - Insite"
TYPE="HTML">
<FONT FACE="Arial, Helvetica, sans-serif" COLOR="990000">
<B>
There has been an error on Insite</B></FONT><BR><BR>
<SPAN CLASS="style4">
Browser Type<BR>
#ERROR.Browser#<BR><BR>
Time Occured<BR>
#DateFormat(ERROR.DateTime)#<BR><BR>
Error Message<BR>
#ERROR.Diagnostics#<BR><BR>
Page User Was Coming From<BR>
#ERROR.HTTPReferer#<BR><BR>
Users IP<BR>
#ERROR.RemoteAddress#<BR><BR>
File Where Error Occured<BR>
#ERROR.Template#<BR><BR>
</SPAN>
</CFMAIL>
Turn off the setting for showing the full path and robust error messages in the CF Admin.
Cross Site Scripting – For CF7
Set protection in CF Administrator or:
In application.cfm
<CFSET THIS.scriptProtect=”all”>
Stop Unauthorized Data Mining
Hackers can change the values of URL or FORM parameters to view other people's data. For example, if you have a parameter user ID=5 in your page's URL variables, they might try running the page with user ID=4 to see what data they can see.
The fix is to prevent users from changing sensitive parameters by using checksums or encryption.
Use URLEncrypt and URLDecrypt from
However, don't get carried away and protect all parameters, because some may be used by other sites linking to you. A classic example is the book ISBN on Amazon's site: most of their URL is one long encrypted string, but the ISBN is left in plain text so that other sites can link to books on Amazon's site.
Use variable for DSN
Gives hackers less information to work with. Define it as an application variable in Application.cfm.
Remove Dangerous Characters
Use the REReplaceNoCase() function.
Typical characters to remove include: "(", ")", "<", ">", "/", and "|".
Use SafeText function from CFLib to allow some HTML but remove dangerous chars.
Change the ColdFusion MX 7 user account in Windows
The ColdFusion services, by default, run under the highly privileged system accounts. Macromedia recommends instead that you create a Windows user under which you run the services and only give privileges needed to run the web application (for example, folder permissions for the web root.)
To change the ColdFusion MX 7 user account: Open the Services Control Panel. (For example, select Start > Settings > Control Panel > Administrative Tools > Services.) Right-click ColdFusion MX 7 Application Server, and select Properties. The ColdFusion MX 7 Application Server Properties (Local Computer) dialog box appears. On the Log On tab, select This account, and enter the account information. Click OK. In the Services control panel, right-click ColdFusion MX 7 Application Server, and select Restart. Caution: Do not rename your Windows Administrator account. This causes problems with security policies and profiles.
Prevent Fake Form Submits
Hackers can submit fake forms from their server to your submit pages. To prevent this, check the referrer Web page using the CGI variable CGI. HTTP_REFERER. If it is in the same domain as your site, then all is okay. You can test for this either in each submit page or once in your application.cfm file like this:
<CFIF not (CGI.HTTP_REFERER contains "<CFABORT>
</CFIF>
Note: Because the CGI.HTTP_REFERER comes from the browser it can be hacked, so the above test will not stop the determined hacker.
It is also a good idea to protect CFINCLUDE and CFMODULE files from being run stand-alone; they may do bad things or generate error messages. One easy method is to use a common file naming or subdirectory convention for all includes and modules. In the application.cfm test the CGI.script_name to see if it contains this string. The CGI.script_name variable gives you the URL path and filename of the current CFM file being run.
This method is especially important when coding using the Fusebox methodology, because the site structure and certain filenames will be known without seeing your source code. In a Fusebox application only the index.cfm file needs to be run. Here is how you can protect the includes files in this case: In Application.cfm:
<CFIF CGI.script_name contains "index.cfm">
<!--- ok to run --->
<CFELSE>
<CFABORT SHOWERROR="Protected page">
</CFIF>
Alternatively, place included files or cfmodule files outside the Web root.
Harden Your Logon Code
You may have password-protected areas of your site for admin or members only. Be sure that the "front door" of your logon screen is strong.
Require hard passwords from your users - 10 letters or more.
Random password creation - MakePassword at CFLib.
Once all users have strong passwords make them change them every six months.
Don't store passwords in your database, in case a hacker gets a copy of your user database. Instead, store the hash of the password instead of plain text by using the hash() function.
<CFQUERY NAME="CheckPerson" DATA SOURCE="UserData">
SELECT PasswordHash
FROM SecureData
WHERE user ID= <CFQUERYPARAM VALUE="#user ID#" CFSQLType="CF_SQL_CHARVAR"> </CFQUERY>
<CFIF Hash(Form.Password) IS NOT CheckPerson.PasswordHash>
<CFLOCATION URL="unauthenticated.cfm">
<CFELSE>
<CFLOCATION URL="authenticated.cfm">
</CFIF>
For a really secure login, consider timing out the login for an hour for a particular user ID after three failures at logging in. This prevents hackers from automatically trying thousands of common passwords via an automated submit program.
Prevent Timeout Client/Session Backdoors
When you are using client or session variables to protect secure areas of your site there is still the problem of your users leaving their machines logged in while they go to lunch. A hacker could see the open browser and steal confidential data.
For this reason it is wise to use a short timeout of 10 minutes. Normally I handle this in my code rather than changing how long the session or client variables exist. Partly because it is easy for me to control and customize for each user, but also so that while I log out users automatically, I can still offer them the chance to reenter their password and not lose any data that is stored in their session.
I would also suggest that you make the associated session/client cookies CFID and CFTOKEN automatically delete after the browser closes. Otherwise a hacker may open the browser and use the history feature to go to your secure pages if the user forgot to log out.
<cfcookie expires="NOW" name="CFID" value="#cookie.cfid#">
<cfcookie expires="NOW" name="CFTOKEN" value="#cookie.cftoken#">
This keeps the current cookie names and values but makes sure that they disappear when the browser closes.
Avoid Trojan Horse Uploads
Some sites let you upload graphics or other files. If you are not careful, hackers can use this feature to upload program files and then run them from your Web site. Or they might try to overwrite critical system files by using ../ paths.
To prevent this, always store uploaded files outside your Web root and strip out any path information from filenames. Set appropriate permissions on these subfolders.
Also be careful if you use CFCONTENT to display a file where the filename is given via a URL parameter. The page can be misused to send back your source code if a hacker gives the path and name of your CFM files instead of a graphic. Again, storing displayed files outside of the Web root helps, as does validating that the parameter filename does not contain any path such as "../".
Cheers,
Bluetone
SQL Injection
Use URLEncrypt and URLDecrypt from
For Form fields, use a Checksum field
Calling page:
<input type="hidden" name="ID" value ="#GetBouquets.BouquetID#">
<input type="hidden" name ="checksum" value ="#hash(GetBouquets.BouquetID)#">
In the submit page:
<CFIF hash(FORM.ID) neq FORM.checksum>
Bad Form
<CFABORT>
</CFIF>
The hash() function gives a check sum for a string so if the string is changed, the hash of it will change too. For multiple hidden fields first combine them into one string, then hash that. It doesn't matter how long the string is, the hash function always returns 32 characters.
Validate all URL and FORM parameters with the CFPARAM tag. To make sure that a URL parameter is supplied, leave out the DEFAULT parameter of CFPARAM and an error will be thrown if the URL variable is missing.
Use CFPARAM
One way hackers can hurt your site is by running bad SQL in your queries by typing the extra SQL into URL or FORM parameters that you use in your CFQUERY statements.
A little-known feature of SQL Server is that you can run two SQL statements from one CFQUERY by separating them with a semicolon. Hackers exploit this by injecting extra SQL via URL parameters. For example, suppose you have a CFQUERY in page.cfm that contains the following SQL:
SELECT * FROM EMP WHERE ID = #URL.USER ID#
And normally the page is run like this:
ID=7
This will cause the following SQL to be run in your CFQUERY:
SELECT * FROM EMP WHERE ID=7
Now the hacker adds extra SQL commands on the end of the URL variable (the %3B and %20 encode a semicolon and a space, respectively, in a URL string):
ID=7%3BDELETE%20FROM%20CustomerTable
This will cause the following SQL to be run in your CFQUERY:
SELECT * FROM EMP WHERE ID=7 ;DELETE FROM CustomerTable
This will run both SQL commands and delete all your records from the table CustomerTable.
Other attacks use the vertical bar character (|) to run VBA functions in Access. One of the most dangerous VBA functions is shell(), which will run any command string in a shell on your server. Just think what a FORMAT command might do to your server.
In SQL Server the similar xp_cmdshell function is equally dangerous and can be turned off in the SQL Server admin.
To prevent SQL injection hacking, use <CFQUERYPARAM> on all SQL parameters.
A side benefit of using CFQUERYPARAM is that your queries will run faster because SQL Server or Oracle will be more likely to use a cached query plan instead of recalculating the query plan from scratch.
Note: Some programmers use the ColdFusion val() function to protect numeric parameters, but CFQUERYPARAM also works with other datatypes and - unlike val - it generates an error when the data type is incorrect. Also, the previous tips on removing dangerous characters and encrypting URL variables help to prevent SQL injection attacks, but these should be used only in addition to CFQUERYPARAM, and not instead of it.
<CFPARAM NAME = "somename" DEFAULT="something" TYPE="UUID STRUCT STRING QUERY NUMBERIC DATE BOOLEAN BINARY ARRAY>
<cfquery name="EmpList" datasource="CompanyInfo">SELECT * FROM Employee WHERE Emp_ID = <cfqueryparam value = "#Emp_ID#" cfsqltype = "cf_sql_integer">
</cfquery>
Mask Error Handling
Create Error Handler - add CFERROR tags application.cfm
<CFERROR TYPE="REQUEST" TEMPLATE="Other/Error1.cfm">
<CFERROR TYPE="Exception" TEMPLATE="Other/Error3Email.cfm">
<CFMAIL
FROM="webmaster@precorp.coop"
TO="shaneh@precorp.coop"
SUBJECT="Error Report - Insite"
TYPE="HTML">
<FONT FACE="Arial, Helvetica, sans-serif" COLOR="990000">
<B>
There has been an error on Insite</B></FONT><BR><BR>
<SPAN CLASS="style4">
Browser Type<BR>
#ERROR.Browser#<BR><BR>
Time Occured<BR>
#DateFormat(ERROR.DateTime)#<BR><BR>
Error Message<BR>
#ERROR.Diagnostics#<BR><BR>
Page User Was Coming From<BR>
#ERROR.HTTPReferer#<BR><BR>
Users IP<BR>
#ERROR.RemoteAddress#<BR><BR>
File Where Error Occured<BR>
#ERROR.Template#<BR><BR>
</SPAN>
</CFMAIL>
Turn off the setting for showing the full path and robust error messages in the CF Admin.
Cross Site Scripting – For CF7
Set protection in CF Administrator or:
In application.cfm
<CFSET THIS.scriptProtect=”all”>
Stop Unauthorized Data Mining
Hackers can change the values of URL or FORM parameters to view other people's data. For example, if you have a parameter user ID=5 in your page's URL variables, they might try running the page with user ID=4 to see what data they can see.
The fix is to prevent users from changing sensitive parameters by using checksums or encryption.
Use URLEncrypt and URLDecrypt from
However, don't get carried away and protect all parameters, because some may be used by other sites linking to you. A classic example is the book ISBN on Amazon's site: most of their URL is one long encrypted string, but the ISBN is left in plain text so that other sites can link to books on Amazon's site.
Use variable for DSN
Gives hackers less information to work with. Define it as an application variable in Application.cfm.
Remove Dangerous Characters
Use the REReplaceNoCase() function.
Typical characters to remove include: "(", ")", "<", ">", "/", and "|".
Use SafeText function from CFLib to allow some HTML but remove dangerous chars.
Change the ColdFusion MX 7 user account in Windows
The ColdFusion services, by default, run under the highly privileged system accounts. Macromedia recommends instead that you create a Windows user under which you run the services and only give privileges needed to run the web application (for example, folder permissions for the web root.)
To change the ColdFusion MX 7 user account: Open the Services Control Panel. (For example, select Start > Settings > Control Panel > Administrative Tools > Services.) Right-click ColdFusion MX 7 Application Server, and select Properties. The ColdFusion MX 7 Application Server Properties (Local Computer) dialog box appears. On the Log On tab, select This account, and enter the account information. Click OK. In the Services control panel, right-click ColdFusion MX 7 Application Server, and select Restart. Caution: Do not rename your Windows Administrator account. This causes problems with security policies and profiles.
Prevent Fake Form Submits
Hackers can submit fake forms from their server to your submit pages. To prevent this, check the referrer Web page using the CGI variable CGI. HTTP_REFERER. If it is in the same domain as your site, then all is okay. You can test for this either in each submit page or once in your application.cfm file like this:
<CFIF not (CGI.HTTP_REFERER contains "<CFABORT>
</CFIF>
Note: Because the CGI.HTTP_REFERER comes from the browser it can be hacked, so the above test will not stop the determined hacker.
It is also a good idea to protect CFINCLUDE and CFMODULE files from being run stand-alone; they may do bad things or generate error messages. One easy method is to use a common file naming or subdirectory convention for all includes and modules. In the application.cfm test the CGI.script_name to see if it contains this string. The CGI.script_name variable gives you the URL path and filename of the current CFM file being run.
This method is especially important when coding using the Fusebox methodology, because the site structure and certain filenames will be known without seeing your source code. In a Fusebox application only the index.cfm file needs to be run. Here is how you can protect the includes files in this case: In Application.cfm:
<CFIF CGI.script_name contains "index.cfm">
<!--- ok to run --->
<CFELSE>
<CFABORT SHOWERROR="Protected page">
</CFIF>
Alternatively, place included files or cfmodule files outside the Web root.
Harden Your Logon Code
You may have password-protected areas of your site for admin or members only. Be sure that the "front door" of your logon screen is strong.
Require hard passwords from your users - 10 letters or more.
Random password creation - MakePassword at CFLib.
Once all users have strong passwords make them change them every six months.
Don't store passwords in your database, in case a hacker gets a copy of your user database. Instead, store the hash of the password instead of plain text by using the hash() function.
<CFQUERY NAME="CheckPerson" DATA SOURCE="UserData">
SELECT PasswordHash
FROM SecureData
WHERE user ID= <CFQUERYPARAM VALUE="#user ID#" CFSQLType="CF_SQL_CHARVAR"> </CFQUERY>
<CFIF Hash(Form.Password) IS NOT CheckPerson.PasswordHash>
<CFLOCATION URL="unauthenticated.cfm">
<CFELSE>
<CFLOCATION URL="authenticated.cfm">
</CFIF>
For a really secure login, consider timing out the login for an hour for a particular user ID after three failures at logging in. This prevents hackers from automatically trying thousands of common passwords via an automated submit program.
Prevent Timeout Client/Session Backdoors
When you are using client or session variables to protect secure areas of your site there is still the problem of your users leaving their machines logged in while they go to lunch. A hacker could see the open browser and steal confidential data.
For this reason it is wise to use a short timeout of 10 minutes. Normally I handle this in my code rather than changing how long the session or client variables exist. Partly because it is easy for me to control and customize for each user, but also so that while I log out users automatically, I can still offer them the chance to reenter their password and not lose any data that is stored in their session.
I would also suggest that you make the associated session/client cookies CFID and CFTOKEN automatically delete after the browser closes. Otherwise a hacker may open the browser and use the history feature to go to your secure pages if the user forgot to log out.
<cfcookie expires="NOW" name="CFID" value="#cookie.cfid#">
<cfcookie expires="NOW" name="CFTOKEN" value="#cookie.cftoken#">
This keeps the current cookie names and values but makes sure that they disappear when the browser closes.
Avoid Trojan Horse Uploads
Some sites let you upload graphics or other files. If you are not careful, hackers can use this feature to upload program files and then run them from your Web site. Or they might try to overwrite critical system files by using ../ paths.
To prevent this, always store uploaded files outside your Web root and strip out any path information from filenames. Set appropriate permissions on these subfolders.
Also be careful if you use CFCONTENT to display a file where the filename is given via a URL parameter. The page can be misused to send back your source code if a hacker gives the path and name of your CFM files instead of a graphic. Again, storing displayed files outside of the Web root helps, as does validating that the parameter filename does not contain any path such as "../".
Cheers,
Bluetone
imstillatwork
IS-IT--Management
very, very nice! It would take hours to find all that (I know, I've looked)
this should be considered MUST READ for all CFers.
If you don't mind, I would like to use this as the reference for a section of my little CF info site. I think all my bookmarks are on my old PC.
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
this should be considered MUST READ for all CFers.
If you don't mind, I would like to use this as the reference for a section of my little CF info site. I think all my bookmarks are on my old PC.
Kevin
Phase 1: Read the CFML Reference
Phase 2: ???
Phase 3: Profit!
- Status
Similar threads
- Locked
- Question