I have a small CF9 app, no database involved. In the configuration I need to store a network password which one of the functions needs, but I don't want to have it stored in the Application.cfc (for example) in human readable form.
What's the best way of storing/reading the password?
Step 1: On a web page that is not going into production, run:
<cfoutput>#hash('My_pa55w0rd')#</cfoutput>
That will show a hash of the password.
Step 2: On a web page that is going into production, add the hash to a variable such as application.pass_hash . Verify against pass_hash as needed.
<cfif hash(form.password) EQ application.pass_hash>
<p>Successful login!</p>
</cfif>
Related
I inherited some legacy ColdFusion code and about a year ago my site was hit with XSS and SQL injection.
Which cause me to validate inputs coming in as well as including a setting of ScriptProtect="all" in my application.cfm file. I got it scan and it came up clean.
Recently I had it scanned again and it came up with many vulnerabilities in particular one where it embedded a script in the url.
For example this was attached to a url:
?’A<style > a(font0family:expression(alert(2424)))</style>
Which embedded a hidden JavaScript. How would one use a ColdFusion function such as URLencode() in the application.cfm file to detect/prevent these sort of XSS attacks?
There are a few specific things you can do, depending on the nature of the attacks and the type of application. The following are what I would consider to be "the big three". The first item is to enable the "Enable Global Script Protection" in the "Settings" area of the Coldfusion administrator.
The second, and this is extremely important for SQL injection, is to use <cfqueryparam> with strict typing on any variable used in your queries. For example:
<cfqueryparam cfsqltype="cf_sql_integer" value="#my_integer#">
On a script-based query this would be accomplished by:
<cfscript>
qget = new query(datasource=my_datasource);
qget.addParam(name='my_integer',value=url.my_id,cfsqltype='cf_sql_integer');
qresult = qget.execute(sql='
SELECT * from my_table
WHERE id = :my_integer
').getResult();
</cfscript>
The third, is dependent on whether you are using JSON from your application via an API or internal call. Enabling the "Prefix Serialized JSON" setting in the CF Administrator with a prefix of your choice can help with cross-site scripting attacks as well.
If you're not on a Adobe CF server, no worries. Both Railo and Blue Dragon have equivalent features.
Suppose my django project gets some cookies from a server application (the webclient itself still gets django generated cookies). When I login django website, I ask for a cookie from that server application. It is currently saved in database, but we don't want this method.
My question is: does saving this cookie in request.session['special_cookies'] safe? How long does this information last?
What is a better way to save this information throughout browsing? Thanks.
Yes, that's safe. It's still a database hit, though: in the standard Django configuration, session data is pickled into a binary data field in the session. It's just provided for you "out of the box" rather than your having to store it yourself. You can improve performance by using the cached_db setting and giving memecache a lot of the details.
RTFM, please.
I have web site with source code in ColdFusion. How can I find out which database is used and where is database files?
Thank you!
Also, I haven't access to CF Admin.
Assuming you are using CF8 or later:
If you have the datasource (which you can see in the CFQUERY/CFSTOREDPROC) you can use cfdbinfo to get database information.
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_d-e_01.html for details.
Search through the entire codebase for instances of the tag <CFQUERY> (and additionally <CFSTOREDPROC>).
Look at the value entered into the attribute "datasource", collect them all up.
If you have access to CF Admin:
Log into the ColdFusion Administrator, navigate to Datasources, and match the datasource names with the ones you found in your search.
Examine the DSN settings. They are your databases.
If you do not have access to CF Admin:
Pass the names of the datasources to <CFDBINFO> and dump out the results (thnx to TheCycoONE)
Shawn hit it: you'll have to get into the ColdFusion Administrator's Datasource settings. Find the name of the datasource in your Application.cfm/cfc/direct in the query, then in click that DSN in the administrator. It should tell you which db (type) connector it's using, and the general location.
I have a CF9 project set up with a multi-tiered directory structure. At the root level I have the live production site with its Application.cfc. It contains a number of variables that are bound to a 'debugMode' flag--so in the case of the production site, this flag is set to false.
In a subdirectory of the production site, I have a folder containing a testing version of the site. This has its own Application.cfc with debugMode set to true. Other than this flag and changes that we are testing, it's identical to the production Application.cfc.
There haven't been any problems with this UNTIL we added logic for resetting Application.cfc in order to see our changes without waiting for the timeout (which we have set to 30 minutes).
To accomplish this, we added this block to the 'OnRequestStart' function in Application.cfc (it is present on both production and testing versions):
<cfif StructKeyExists( URL, "reset" )>
<!--- Reset application and session. --->
<cfset THIS.OnApplicationStart() />
<cfset THIS.OnSessionStart() />
</cfif>
This initially appeared to work fine. If we add '?reset' to the url for any page on the testing version, changes made Application.cfc are reflected immediately, but we quickly discovered a nasty side effect: calling reset on the testing version ALSO changes our production site to use the testing version of Application.cfc, thereby mightily fubaring everything.
Running the '?reset' logic on the production site fixed this problem, but then caused all the testing pages to use the production Application.cfc instead of the testing version. Waiting for the Application.cfcs to time out and refresh automatically made no difference, so now our test environment is messed up.
Any insight into what's going on or what to do would be greatly appreciated as we are fairly stumped. Is this simply a poor architecture? We inherited it and are now quite accustomed to this structure, so so a quick fix would be preferred, but I'm open to suggestions.
Thanks.
The issue is most likely that the two application.cfc files specify the same application name.
So, they are, in essence, the same application.
So, whether you trigger the refresh from the "Test" site or the "Live" site, its resetting the same application, then re-instantiating the variables from whatever version you issued the reset from.
You need to set the application name for the "Test" application to something different then the live application.
For Test:
<!--- For the "Test" Application --->
<cfset this.name = "TESTApplication">
For Live:
<!--- For the "Live" Application --->
<cfset this.name = "Application">
I have a Dotnetnuke environment with multiple portals running at different subdomains (serviceA.company.com, serviceB.company.com). I can allow users the access to each portal by adding rows to UserPortals table, but since DNN uses full domain name in the auth cookie, the users need to log separately to each portal.
I'd like to have the system working so, that you only need to log in once on some of the portals, and wouldn't have to log in on the others. Is this possible?
This is possible by changing the web.config.
It's been a while since I did this, but I think you need to change the following
<httpCookies httpOnlyCookies="true" requireSSL="false" domain="" />
to
<httpCookies httpOnlyCookies="true" requireSSL="false" domain="*.company.com" />
I might be off on the setting, but there is a way to do this in the web.config. Let me know if that works.