General discussion


App development best practices

By MirrorMirror ·
I was recently tasked with assessing vulnerabilities on some of my companies database servers and the applications that connect to them. I have been asked as part of the documentation to provide a list of best practices. We are a small shop that has not had a set standards or security policy so this is new.

Here is what I have so far, let me know what I can add or what you use.

1. Only display essential data on web pages.
2. Make sure that application users and connections have bare minimum rights on the database server.
3. Sanitize data that is freely input by users.
4. Use prepared statements to send precompiled SQL statements.
5. Never allow client supplied data to modify the syntax of SQL statements.
6. Isolate the web application from SQL altogether.

I really appreciate any input!

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Uniquely ID users

by radobson In reply to App development best prac ...

To the greatest degree possible use unique identifiers for your DB users. This allows you to manage access at a finer level and ensure than any malicious input is traceable.
Using directory service, such as the one used for network authentication (AD in Windows) is an excellent way to do this.

Collapse -

Data is the treasure and need to be kept that way

by GordonK In reply to App development best prac ...

I believe that separating the data of your internal database system and web site is essential (depending on size of the company, it's industry and the purpose of building a website).

If a company's main source of revenue is the web then these rules may not apply. But if your company is smaller and web revenue is only a portion of your total revenue then data separation may give you an extra security.

Data separation meaning 2 separate databases or at least different tables. Data from your system database would be migrated to the web database periodically (here you can define the period lenght according to your needs) and also orders could be downloaded from web database to the system database periodically.

This will give you the following advantage:
1) web users can have access to web database and you make sure that there is no threat of getting more data than you would like
2) the upload/download routine controls the pace of your updates (a complex item master maintenance can be uploaded to the web database after the entire maintenance has finished, this is even more true if you're speaking of pricing)
3) also typically what I've seen at some of the clients there is a difference in discounts offered to regular customers ordering directly and web orders (pricing may be embedded to the system database without the need of accessing it all from the web database)

Collapse -


by apotheon In reply to Data is the treasure and ...

Not only should the data model be separated from the rest of the application (and the persistent data even separated from the data model to a certain extent), but the application itself should be separated into view and controller parts (interface and program logic, essentially). Thus, the Model-View-Controller development architecture.

Collapse -

the design should

by Jaqui In reply to App development best prac ...

isolate the data sources from the web pages as much as is possible.

the page that calls the query is calling an executable script [ cgi ] that returns the required result set in a web page format.

the end user of the site gets nothing that exposes the database structure, and can't use any page they see to get data that may allow them to breach the site security.

always sanitise every bit of user supplied data.

make sure that your scripts use absolute uri instead of relative. this helps avoid cross site vulnerabilities. [ in case you sell the scripts to another company, their version is set to thier site not yours ]

user data should be set by the get method, instead of the standard post method, this obsures the data so that you don't have the fields being dispayed at all in the url.
[ 5218-11195-0.html?forumID=87&threadID=186554&messageID=1909270 ] from the url while posting this reply, I have now that this discussion is forum # 87 thread # 186554 and post # 1909270. if I was to track the numbers, I could then attempt to completely rewrite the database for an entire thread by putting sql commands into the url.
[ naturally, TR would get logs of this and nail me for being that stupid, but that is exactly how a lot of people hack websites ]

Related Discussions

Related Forums