Is my AJAX site secure enough?
- Thread starter christy
- Start date
So I'm working on an AJAX with PHP, mysql backend and I'm trying to ensure my practices are as secure as possible. In particular, I'm using JSON as my data interchange format. Basically, If I'm appending a bit of poorly formatted JS in front of my JSON string, checking if it's there and then removing it before parsing the JSON string, eliminating all script tags from the JSON strings to prevent an malicious code injection, and validating all of my data in and out using white listing methods, do I have myself covered in preventing XSS and CRSF? Are these methods all solid implementations or am I missing anything?
So I'm working on an AJAX with PHP, mysql backend and I'm trying to ensure my practices are as secure as possible. In particular, I'm using JSON as my data interchange format. Basically, If I'm appending a bit of poorly formatted JS in front of my JSON string, checking if it's there and then removing it before parsing the JSON string, eliminating all script tags from the JSON strings to prevent an malicious code injection, and validating all of my data in and out using white listing methods, do I have myself covered in preventing XSS and CRSF? Are these methods all solid implementations or am I missing anything?
Allow me to clairfy a couple facts. I am validating all input on both client and server. Using sessions to authenticate and form tokens to validate the user input. I'm also using SSL. My question is primarily concerned with XSS and CRSF in terms of JSON data formats. I apologize for confusion
So I'm working on an AJAX with PHP, mysql backend and I'm trying to ensure my practices are as secure as possible. In particular, I'm using JSON as my data interchange format. Basically, If I'm appending a bit of poorly formatted JS in front of my JSON string, checking if it's there and then removing it before parsing the JSON string, eliminating all script tags from the JSON strings to prevent an malicious code injection, and validating all of my data in and out using white listing methods, do I have myself covered in preventing XSS and CRSF? Are these methods all solid implementations or am I missing anything?
Allow me to clairfy a couple facts. I am validating all input on both client and server. Using sessions to authenticate and form tokens to validate the user input. I'm also using SSL. My question is primarily concerned with XSS and CRSF in terms of JSON data formats. I apologize for confusion
Two things:
1. As you've described, the data is sanitized at the client side. This is not a good practice. Input sanitation allows you to both secure the database (which is the whole point of the routine) and to centralize the analysis of the data. Do remember, the client bound data is unencrypted thus even with client side processing, various components that you do not intend to express may still be visible.
2. It seems as if you're more concerned with the actual concept of securing your website rather than the practice. Most modern browsers are your first and only line of defense for most of the client level exploits. Failing that, there's not much that you can do to protect those with legacy browsers.
More important however are the server side protections. I have literally gone through dozens of security incidents within the past year alone running on a suite of extensively tested proprietary software; all of these incidents were server-side attacks.
1. As you've described, the data is sanitized at the client side. This is not a good practice. Input sanitation allows you to both secure the database (which is the whole point of the routine) and to centralize the analysis of the data. Do remember, the client bound data is unencrypted thus even with client side processing, various components that you do not intend to express may still be visible.
2. It seems as if you're more concerned with the actual concept of securing your website rather than the practice. Most modern browsers are your first and only line of defense for most of the client level exploits. Failing that, there's not much that you can do to protect those with legacy browsers.
More important however are the server side protections. I have literally gone through dozens of security incidents within the past year alone running on a suite of extensively tested proprietary software; all of these incidents were server-side attacks.