Disable SQL error output on production

[willdoran]

Expected behaviour

• Properly escape and filter user input. Only use prepared statements whencommunicating with a SQL database. Use additional escaping on the backend if thisis not already present. Don't return any SQL errors to the client.

Actual behaviour

• Sql errors appeared on several pages. It was possible to injectSQL commands but getting a working query was not possible.

Steps to reproduce the behaviour/error

[rjmackay]

Looking at the referenced pages. We are using prepared statements, and escaping, however we're still outputting debug info in production.

We just need to fix this in the deployment scripts

[rjmackay]

@tuxpiper could you look at this? we should be setting KOHANA_ENV=production

[rjmackay]

Hrm. Actually maybe I'm wrong. We might still be outputting the error regardless of KOHANA_ENV. Guess we need to sanitize those errors somehow

[tuxpiper]

yep we have KOHANA_ENV=production everywhere I checked

[rjmackay]

I've set APP_ENV and APP_DEBUG in the lumen builds now. This should be resolved once lumen gets to production

[rowasc]

Closing as lumen is out now

[rowasc]

Reopening this needs to be verified in prod

[rjmackay]

It looks like there are still some minor issues.

• A url like https://quakemap.api.ushahidi.io/api/v3/roles?orderby=create`d&order=desc&limit=100&offset=100 will generate an SQL error. The backtick is escaped properly but the SQL is still being returned in the error
• Tampering with post data to include an id in a new post still causes a duplicate key error.

[tuxpiper]

A url like https://quakemap.api.ushahidi.io/api/v3/roles?orderby=create`d&order=desc&limit=100&offset=100 will generate an SQL error. The backtick is escaped properly but the SQL is still being returned in the error

This seems to have been resolved . I am no longer getting any SQL .

[tuxpiper]

Tampering with post data to include an id in a new post still causes a duplicate key error.

Not only that, but if the chosen ID is not duplicate, the operation goes ahead without a hitch. I don't think choosing the ID of the post should be allowed. Looks like maybe this needs its own issue? (thoughts @rowasc? )

[rowasc]

oh. Yea the id should not be allowed in POST operations @tuxpiper Yea a new issue would be fine for the new use case and then we can close this one

[tuxpiper]

Closing since it's not occurring anymore .

Opened #3600 for the other anomalous behavior reported in comments.