Thanx to some good ole fashioned hackers... They are trying to insert some trash code.
20-Feb-21'[0] is not a valid date/time format
20-Feb-21'[A=0] is not a valid date/time format
By slipping in bad code into my date time or wherever.
So I am controlling some things this way.
<cfif #cgi.query_string# contains '{0}'>
<cfabort>
</cfif>
But is there a way I can just validate the string and if bad - do the same thing?
It doesn't happen often, but I just happen to be looking at the log files and saw this garbage.
I am also killing any known bots if I can sniff them...
<cfif #cgi.HTTP_USER_AGENT# contains 'bot'>
<cfabort>
</cfif>
Any other suggestions folks. Thx.
Related
What is the best way to stop Cross-Site Scripting for ColdFusion?
Is there a setting to set in the CF Admin or is their code in you can put in Application.cfc?
Example Code:
http://test.com/file.cfm?center=fisCenter')" onmouseover="alert('Insert Hax Here.')" style="display:block;position:absolute;top:0;left:0;width:10000px;height:10000px;z-index:100">
First things first: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet. OWASP has tons of resources to help devs better understand the problem. XSS isn't a CF problem, but a webdev problem.
That said, which version of CF are you working with? It's more difficult to deal with in CF9 or lower. Those versions have limited built-in functionality and may require falling back into Java methods, if able. But CF10 added a bunch of functionality.
HTTPOnly Cookies - while "available" well before CF10, CF10 added it as a setting in CF Administrator or by using this.sessioncookie.httponly=true in Application.cfc. You can still accomplish this in older versions through JVM settings or content headers. (https://www.petefreitag.com/item/764.cfm)
Content Secruity Policy - (https://content-security-policy.com/) I will admit that I'm not as familiar with CSP as I should be. It's not really CF, but it's still something to know about. It lets you establish the approved origin of the content in your site, which should hopefully prevent someone from injecting content that redirects a user's action to somewhere else. But be warned that it is browser-dependent.
scriptProtect is a CF Admin or Application.cfc setting. (http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7d69.html) will help with a lot of XSS, but not all. It's a simple pattern-matching blacklist method instead of a whitelist (it pretty much looks only for object, embed, script, applet, and meta), so there are many ways to get around it. It should be used but not relied upon or expected to be 100% safe.
encodeFor*() - (https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-functions/functions-e-g/encodeforhtml.html). These have been much improved since the HTMLEditFormat() days. Make sure you use the appropriate encoding method.
Canonicalize() - (https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-functions/functions-c-d/Canonicalize.html) This function is great, but I believe there was a minor change between 10 and 11 that adds a little better handling. With the additional CF11 throwOnError flag, when you check for both multi- and mixed encoding, you can throw/catch an error if either are detected and log/block that user. There is pretty much no reason any legitimate user would ever hit those flags, so logging/blocking isn't a bad idea.
Also see Dave Epler's excellent writeup in http://learncfinaweek.com/week1/Cross_Site_Scripting__XSS_/. That will give you some good info on XSS in ColdFusion.
And finally, as you can see from some of my earlier links, Pete Freitag has some the best security resources I've found (https://www.petefreitag.com), and he tends to be the expert I trust for information about ColdFusion application security. Pete's Bank of Insecurity app (https://github.com/foundeo/cfml-security-training) will give you some great examples of how CF can be exploited.
The moral of my story is one of basic Defense In Depth, even for a single type of exploit. Some of my examples above involve code you write, some are page headers (not quite the same kind of code) and some are Server Administrator functions or settings. You can never be 100% safe, but it's a good idea to throw multiple roadblocks up in the way of a malicious user.
This seems to be the answer I was looking for so far.
<!--- In Application.cfc --->
<cfscript>
this.scriptprotect = "all";
</cfscript>
<!--- In OnRequestStart in Application.cfc --->
<cfscript>
sanitizeScope(url);
</cfscript>
<!--- CF10 Canonicalize --->
<cfscript>
/* This function decodes any particular scope values */
public void function sanitizeScope( struct scope )
{
for( var key in scope )
{
scope[key] = canonicalize(scope[key], false, false);
}
}
</cfscript>
Dear Wordpress developers
I have been unable to find a clear answer to this question, which is inspired by this post by jared about sanitization and this article by Theme Foundation about the Theme Customizer. Particularly, here is a quote from the latter:
If the input is a 1 (indicating a checked box) then the function
returns a one. If the input is anything else at all, the function
returns a blank string. This prevents anything harmful from being
saved to the database.
That last line about preventing harmful things from being saved to the database is something we can all agree to, I guess. But what I don't get is how you can get harmful anything from a checkbox - unless you make programming errors - since there are only two possible values?
So if sanitization in such cases are there to prevent just that: "data corruption" due to programming errors, I don't know if it is a good or a bad thing.
I think it only makes sense to sanitize data when your inputs are text or textfields - at least when protection against harmful stuff is your goal. I get that you sometimes need to format the data to make them useful, but that is a different subject.
That last line about preventing harmful things from being saved to the
database is something we can all agree to
The thing is that "harmful" is very much about context. JavaScript in the database isn't harmful on its own - it is only "harmful" if output to HTML in another user's session. The upshot of it is that this type of vulnerability (XSS) is better dealt with via output encoding. That is, when the content is output to the page then it should be HTML encoded. This would make a script tag be output as <script;> which does nothing more than actually output the literal <script> to the displayed page.
But what I don't get is how you can get harmful anything from a
checkbox - unless you make programming errors - since there are only
two possible values?
Not if an attacker manipulates the POSTed data. For example, if your checkbox is defined as
<input type="checkbox" name="agreeToTCs" />
this would send agreeToTCs=on to your application when checked.
An attacker could manipulate the POST request though and change this to agreeToTCs=evil. This is the equivalent of specifying
<input type="checkbox" name="agreeToTCs" value="evil" />
in the HTML and the box being checked.
Why is it recommended to sanitize Wordpress Customizer select boxes,
check boxes and radio buttons?
All this boils down to is that your application should only be handling valid data. As a quick example imagine a system that lets you select a user level for a new user when creating one. Part of the system design only lets you specify a user equal or lower than yourself. This is to prevent a low level of user from creating an admin account then gaining full privileges. Say if you are logged in as a medium level user the HTML for the drop down may be rendered as follows:
<select name="userLevel">
<option value="low">low</option>
<option value="medium">medium</option>
</select>
and when this is POSTed to the server e.g. userLevel=medium is sent. However, an attacker may be able to manipulate the POSTed data to userlevel=admin and create themselves an admin user. "Sanitizing" the checkbox again on postback makes sure that your application is only accepting valid values.
I have a client that want's an alias directory name to automatically re-direct to a specific template...
Alias
http://www.host.com/thisplace
Real Path
http://www.host.com/somewhere/file.cfm?var=123&anothervar=567
Any suggestions on the best way to do this?
There are several ways to do this. One way is to set up the 404 handler as a cfm page, then add code to the cfm page to tease out the file name or other variables you are looking for. This works and even works well - but there are some costs associated with it. Here's a link that shows that approach in IIS:
http://mkruger.cfwebtools.com/index.cfm?mode=entry&entry=8F4658E4-0763-5FB7-67D23B839AB74005
We use this approach successfully on a site that serves up HTML 5 "brochures" for marketing. Our admin allows for various keywords to be added and then example.com/keyword triggers the 404 handler -which looks up the keyword and serves the right brochure. So you could do example.com/eatAtJoes - and Joe's cafe brochure would be served. It's flexible and doesn't require lots of care and planning. The keywords simply must be unique and can't reflect any actual folders under the root - that's it. But it does mean triggering a 404 error for every potential keyword - which is not always optimal.
Another way would be to use URLRewrite - but that might involve adding something to your url patter like /go/somewhere - and then using /go/ to identify the pattern and /somewhere to determine the URL var. This approach is the least costly (in terms of web server resources) but might involve more structural changes - i.e. you have to alter your URLs.
I would prefer a solution with URL rewrites like Mart A Kruger describes, but if you're looking for quick solution: Add the following to your onRequestStart method in your Application.cfc:
<cffunction name="onRequestStart" returnType="boolean" output="true">
<cfset sRedirects = structNew()/>
<cfset sRedirects["/thisplace"] = "/somewhere/file.cfm?var=123&anothervar=567"/>
<cfset sRedirects["/otherplace"] = "/somewhere_else/file.cfm?var=456&anothervar=abc"/>
<cfif structKeyExists(sRedirects,CGI.PATH_INFO)>
<cflocation url="#sRedirects[CGI.PATH_INFO]#" statuscode="301"/>
</cfif>
</cffunction>
Again, its a quick-fix and URL rewrites are definitely the way to go in my opinion.
After I submit the form unsuccessfully, the form looses all the values I typed in.
I'm using value="", so that could be related, but if I remove it I get a / in the field, and it still doesn't remember
any idea what I could be doing wrong?
well for now I've used a javascript to do this, it works well but maybe someone has a php/modx/eform solution.
By unsuccessfully submitting the form do you mean it fails validation checks?
No matter what I do, I can't replicate the behaviour you are seeing.
Okay, so I figured it out. I had all the intention of going in and adding the functionality, when I came across line 573 in eform.inc.php "# get SESSION data - thanks to sottwell"
so it's already doing what I want it to.
anyhow, because I couldn't find this in any documentation here is what I've done. Though I must say faintly recall doing this exact thing before. So the next time I need this I might come across this :)
add a value=[+field+]
<input id="femail" name="email" value="[+email+]" eform="Email Address:email:1" />
just remember that the value needs to match the class and NOT the id(unless you want them the same)
For web sites that have username/password text input fields, the browser usually handily offers to remember them for you (in my case, Safari puts them in my OS X keychain).
This simply does not happen with certain web sites. The first example that comes to mind is vBulletin forums. Meaning you can't use a complex/random password unless you're willing to copy and paste it from somewhere each time.
Are browsers detecting when to offer to remember these by "does this look like a username/password" heuristics and failing sometimes?
How does this work behind the scenes?
Edit: Fellow Safari users, check out this combo:
http://8-p.info/greasekit/
http://userscripts.org/scripts/show/8021
http://userscripts.org/scripts/show/28696
There's an 'autocomplete="off"' attribute on form (not officially in HTML4, but generally supported).
Try this:
<form id="loginForm" action="login.cgi" method="post" autocomplete="off">
You could use <FORM METHOD="post" ACTION="action.cgi" AUTOCOMPLETE="off"> but this only works in IE I think.
You could also use a random string for the password field ID so that the browser cannot be sure that a previously entered password is authenticating the same page this time round.
Another strategy would be to not use type="password" as the browser uses this to identify a field as a password - however, this is not a good idea as the password would not be blanked out when the user types it into the form. Any javascript to emulate this would not be executed if JS was disabled.
I think using the first two techniques would probably be as good a solution as is possible without resorting to advising your users to not allow the browser to store passwords.