Input Library
The Input Library serves two purposes:
- It pre-processes global input data for security.
- It provides some helper handlers for fetching input data and pre-processing it.
Note: This library is initialized automatically by the system so there is no need to do it manually.
Security Filtering
The security filtering function is called automatically when a new controller is invoked. It does the following:
- Destroys the global GET array. Since revIgniter does not utilize GET strings (unless you have the query string option enabled in your config file), there is no reason to allow it.
- Filters the POST/COOKIE array keys, permitting only alpha-numeric (and a few other) characters.
- Provides XSS (Cross-site Scripting Hacks) filtering. This can be enabled globally, or upon request.
- Standardizes newline characters to LF
XSS Filtering
revIgniter comes with a Cross Site Scripting Hack prevention filter which can either run automatically to filter all POST and COOKIE data that is encountered, or you can run it on a per item basis. By default it does not run globally since it requires a bit of processing overhead, and since you may not need it in all cases.
The XSS filter looks for commonly used techniques to trigger Javascript or other types of code that attempt to hijack cookies or do other malicious things. If anything disallowed is encountered it is rendered safe by converting the data to character entities.
Note: This function should only be used to deal with data upon submission. It's not something that should be used for general runtime processing since it requires a fair amount of processing overhead.
To filter data through the XSS filter use this function:
rigXssClean()
Here is an usage example:
put rigXssClean(tData) into tData
If you want the filter to run automatically every time it encounters POST or COOKIE data you can enable it by opening your application/config/config.lc file and setting this:
put TRUE into gConfig["globalXssFiltering"]
Note: If you use the form validation library, it gives you the option of XSS filtering as well.
An optional second parameter, pImage, allows this function to be used to test images for potential XSS attacks, useful for file upload security. When this second parameter is set to TRUE, instead of returning an altered string, the function returns TRUE if the image is safe, and FALSE if it contained potentially malicious information that a browser may attempt to execute.
if rigXssClean(tFile, TRUE) is FALSE then
-- file failed the XSS test
end if
rigSanitizeFilename(tFileName, tRelativePath)
Use this function to sanitize filenames from user input to prevent directory traversal and other security related issues. Here is an example:
put rigSanitizeFilename(rigVarPost("filename")) into tFilename
If it is acceptable for the user input to include relative paths, e.g. file/in/some/approved/folder.txt, you can set the second optional parameter, tRelativePath to TRUE.
put rigSanitizeFilename(rigVarPost("filename"), TRUE) into tFilename
Cross-site request forgery (CSRF) Protection
You can enable CSRF protection by opening your application/config/config.lc file and setting gConfig["csrf_protection"] to TRUE. When set to TRUE, token will be checked on a submitted form using the rigFormOpen() function (included in formHelper.lc) and matched with a CSRF cookie. If you are accepting user data, it is strongly recommended CSRF protection be enabled.
put TRUE into gConfig["csrf_protection"]
Using the form helper and the rigFormOpen() function will automatically insert a hidden CSRF token field in your forms.
CSRF Preferences
You'll find the following CSRF related preferences in your application/config/config.lc file:
Preference | Default | Options | Description |
---|---|---|---|
csrf_protection | FALSE | TRUE/FALSE (boolean) | Whether to enable CSRF protection. |
csrf_token_name | csrfTokenName | None | The name of the token to be set. |
csrf_cookie_name | csrfCookieName | None | The name of the cookie to be set. |
csrf_expire | 7200 | Time in seconds | The number in seconds from the current time the token should expire. |
Note: Keep in mind that the current time used to calculate expiration time is referenced either to your server's local time or GMT, based on the "time reference" setting in your config file.
Bot Detection
If you are accepting user data you may consider to enable bot detection by opening your application/config/config.lc file and setting gConfig["honeypot"] to TRUE. When set to TRUE, form fields that are hidden but accessible to a Bot, are attached to any form, provided that the rigFormOpen() function (included in formHelper.lc) is used. Requests containing data entered into these honeypot fields are assumed to come from a bot. In this case an error page is shown.
Note: You need to use the form helper and the rigFormOpen() function in order to automatically insert a hidden Bot detection honeypot field in your forms.
Bot Detection Preferences
You'll find the following Bot detection related preferences in your application/config/config.lc file:
Preference | Default | Options | Description |
---|---|---|---|
honeypot | FALSE | TRUE/FALSE (boolean) | Whether to enable Bot detection. |
honeypot_hidden | TRUE | TRUE/FALSE (boolean) | The visibility of the text field. |
honeypot_label | Fill in this field | None | The label of the text field. |
honeypot_name | honeypot | None | The name of the text field. |
honeypot_containerID | rigHP | None | The ID selector of the honeypot container. |
Using POST, COOKIE, or SERVER Data
revIgniter comes with five helper functions that let you fetch POST, COOKIE or SERVER items. The main advantage of using the provided functions rather than fetching an item directly ($_POST["something"]) is that the functions will check to see if the item exists and return false (boolean) if not. This lets you conveniently use data without having to test whether an item exists first. In other words, normally you might do something like this:
if "something" is not among the keys of $_POST then
put FALSE into tSomething
else
put $_POST["something"] into tSomething
}
With revIgniter's built in functions you can simply do this:
put rigVarPost("something") into tSomething
The five functions are:
- rigVarPost()
- rigVarGet() (in case you have the query string option enabled in your config file)
- rigVarGetPost()
- rigVarCookie()
- rigVarServer()
rigVarPost()
The first parameter will contain the name of the POST item you are looking for:
get rigVarPost("someData")
The function returns FALSE (boolean) if the item you are attempting to retrieve does not exist.
The second optional parameter lets you run the data through the XSS filter. It's enabled by setting the second parameter to boolean TRUE;
get rigVarPost("someData", TRUE)
rigVarGet()
This function is identical to the post function, only it fetches get data:
get rigVarGet("someData", TRUE)
rigVarGetPost()
This function will search through both the post and get streams for data, looking first in post, and then in get:
get rigVarGetPost("someData", TRUE)
rigVarCookie()
This function is identical to the post function, only it fetches cookie data:
get rigVarCookie("someData", TRUE)
rigVarServer()
This function is identical to the above functions, only it fetches server data:
get rigVarServer("someData")
Dealing with LiveCode Arrays in Post Data
You can send LiveCode arrays to revIgniter using POST. For this to work the following headers must be sent along with the POST data: "Content-Type: application/lc.array" or "Content-Type: application/lc.array.compressed" respectively in case you like to send your array in compressed form.
Use
put base64Encode(arrayEncode(myArray)) into tMyPreparedArray
or
put base64Encode(compress(arrayEncode(myArray))) into tMyPreparedArray
to prepare LiveCode arrays on the client side.
Then format your data using LiveCode's libURLFormData() function like:
put libURLFormData("myArray", tMyPreparedArray, "myOtherArray", tMyOtherPreparedArray, "keyForSomeString", "myString") into tDataToSend
Alternatively, you can post without formatting the data like:
put tMyPreparedArray into tDataToSend
Set the correct header and send the data to revIgniter:
set the httpHeaders to "Content-Type: application/lc.array.compressed"
post tDataToSend to URL "http://mysite.com/mycontroller/"
If you send the data as form data, you can retrieve your data on the server side like:
put rigVarPost("myArray") into tMyArray
Otherwise use as function parameter (the key name of the $_POST array) "rigLCArray" to retrieve the data like:
put rigVarPost("rigLCArray") into tMyArray
Dealing with JSON in Post Data
To post JSON send "Content-Type: application/json" along with the POST data. There is no need to send JSON as form data.
On the server side JSON data can be retrieved from $_POST and from $_POST_RAW as well as from rigVarPost() or from rigVarPost(, TRUE) respectively.
If you like you can post JSON as form data too. Assuming that the name of the first form part is "myJSONdata", the JSON data can then be retreived from rigVarPost("myJSONdata") or from rigVarPost("myJSONdata", TRUE) respectively.
User Agent and IP Address
rigIpAddress()
Returns the IP address for the current user. If the IP address is not valid, the function will return an IP of: 0.0.0.0
put rigIpAddress() into tIP
rigValidIP(tIP)
Takes an IP address as input and returns TRUE or FALSE (boolean) if it is valid or not. Note: The rigIpAddress() function above validates the IP automatically.
if rigValidIP(tIP) is FALSE then
put "Not Valid" into tUserIP
else
put "Valid" into tUserIP
end if
Accepts an optional second string parameter of "IPv4" or "IPv6" to specify an IP format. The default checks for both formats.
rigUserAgent()
Returns the user agent (web browser) being used by the current user. Returns FALSE if it's not available.
put rigUserAgent() into tUserAgent