<![CDATA[ Security, security, security! - MODX Community Forums]]> https://forums.modx.com/thread/?thread=20171 <![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-414138 http://videos.code2design.com/video/play/PHP/11]]> goldsky Mar 01, 2012, 04:48 AM https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-414138 <![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112548

Ow, one more thing.
Just be careful when you’re filtering numbers.
Price uses float number.]]>
goldsky Aug 01, 2011, 10:25 AM https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112548
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112547
Actually the only 3rd-party classes coming into play here, apart from the aforementioned Authorize SDK, are those provided by Visioncart team. I have modified their fledgling Authorize module some - changing $_REQUEST to $_POST for one less attack vector.]]>
polrbear Aug 01, 2011, 08:49 AM https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112547
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112546 above, MODx itself sanitizes all the requests trough its index.php gateway, with an option.

What I mean about ’3rd party’ is the part of your scripts that does not belong to MODx (+extras) and your own script.
I’ve never used http://developer.authorize.net/ , but keep your eyes on their security notifications.
To simplify your work, you can use some ready-to-use 3rd party classes to sanitize your input.
I’ve used htmLawed.

I bet you’re using other scripts for several purposes, like Member Management, or Newsletter.
If you’re using those scripts that you find from internet (like from http://phpclasses.org), audit the code.

Or, are you asking about the ’webroot’?]]>
goldsky Jul 31, 2011, 10:26 PM https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112546
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112545 polrbear Jul 30, 2011, 09:36 AM https://forums.modx.com/thread/20171/security-security-security?page=2#dis-post-112545 <![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security#dis-post-112544
If it’s placed on the webroot, you should check the access validation to the direct file.
Especially if you’re using any AJAX processor file.

If you’re using 3rd party classes, check them too.]]>
goldsky Jul 30, 2011, 01:53 AM https://forums.modx.com/thread/20171/security-security-security#dis-post-112544
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security#dis-post-112543 Quote from: goldsky at Apr 05, 2011, 02:22 PM

<?php //highlight
$sanitizedPosts = $modx->sanitize($_POST);
$_POST = array();
$_POST = sanitizedPosts;                      // also can be done

Somewhat new to PHP security issues here. I am building on the Authorize.net payment form for Visioncart, and I want to make sure my code is secure against any kind of script injection badness etc. The credit card form is processed and validated through Formit. Should simply doing recursive sanitizing on $_POST as in this example, called as a preHook, give me a pretty good wall of protection in principle? I realize this question may be too general to answer and I can post specific code if that would help.]]>
polrbear Jul 29, 2011, 03:36 PM https://forums.modx.com/thread/20171/security-security-security#dis-post-112543
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security#dis-post-112542 More tips on using $_GET:

If you use $_GET in your scripts,

  • try to encode it (eg: base64_encode) + use hash if you need to.
  • Salting the value is also very useful, especially if the Salt is not a static value, but a random string that is stored inside the database, which is different to each installed site.

$_GET is a common hole for the hacker to break your site.

That’s also applied to the Ajax processor/controller files.]]>
goldsky May 05, 2011, 06:28 AM https://forums.modx.com/thread/20171/security-security-security#dis-post-112542
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security#dis-post-112541 That’s for the $_POST.
How about the $_GET (let’s say, for the AJAX connector) ?]]>
goldsky Apr 07, 2011, 11:05 AM https://forums.modx.com/thread/20171/security-security-security#dis-post-112541
<![CDATA[Re: Security, security, security!]]> https://forums.modx.com/thread/20171/security-security-security#dis-post-112540
$myObject = $modx->getObject('myClass', $myPK);
if ($myObject) {
    /* fromArray() calls set() for each $_POST var that matches a field in your object */
    /* save() uses prepared statement bindings to automatically quote the values being sent to the db */

But remember, this is just basic sanitization—it is still up to you to define what is and what isn’t valid user input based on specific usage requirements. What if you need to allow some HTML tags? There is a gray area between security and validation here, but a solid combination of both, along with making sure anything that is output back to the user contains nothing that can be exploited (e.g. XSS injection) should always be the goal.

NOTE: There is a System Setting, allow_tags_in_post to allow MODX and HTML tags in the $_POST variable which is enabled by default. To not allow this, for instance in the front-end of your website, you can add this as a Context Setting set to "0" to the web (or any other front-end) Context. This is only enabled by default so that both back-end and front-end content editing solutions will work.]]>
opengeek Apr 05, 2011, 11:49 AM https://forums.modx.com/thread/20171/security-security-security#dis-post-112540