您最好也是最安全的选择是不允许直接输入SQL,而是从您公开给客户端的方法构建。无论何时处理任何字符串数据,check for injection以确保用户不试图绕过您已有的控制。最终用户不应直接调用简单的SQL语句。
例如,使用表“产品”,并揭露这个客户消费,这些方法可能如下所示:
function GetAllProductsByAmount(topn:integer):tDataset;
//Returns all products sorted by amount, no more than topn.}
function GetAllProductsByName(topn:integer):tDataset;
//Returns all products sorted by name, no more than topn}
function FindProductByName(name:string):tDataset;
//returns all products which start with name}
的FindProductByName
功能将有一个检查,以确保不存在名称中的额外引号,如果是,则返回空集。如果第一个查询导致没有数据,我通常也会执行自动通配符查询。
对于下载/上传逻辑,请确保整个请求都通过您的系统。用户文件的存储点应位于未暴露于外部环境的保护区域,但仅供内部使用。当受保护资源的请求进入时,您可以检查凭据,如果它们不正确拒绝该文件。如果一切正常,然后打开并将文件流式传输给用户。
如果你的文件非常大,那么考虑一个带有单独用户的FTP服务器,这样每个用户都有自己的私人目录。这需要更多的维护,但是由于FTP服务器只针对这种访问进行了调整,所以用户可以更快地下载他们的数据。
正如以下注释中所述,由于用户名和密码以纯文本形式发送,因此FTP不够安全。
对于这种类型的应用是我历来做的是创建一个包含一个GUID在服务器上,标志着在最后的有效访问日期/时间(和IP地址)沿着表的会话cookie。会话cookie创建的唯一时间是成功登录后。每次我收到一个请求时,我都会验证这个cookie是否可用,并且仍然有效(比如说30分钟后我才开始扫描),然后更新上次访问的时间戳。如果用户注销,那么我也删除他们的会话cookie。任何包含无效会话Cookie的请求都会重定向到登录页面。这使得事情变得简单,并且减少了在过去30分钟内需要查看谁在线的数据量(或者未注销并且尚未清理)。我会自动清除所有在每次登录/注销尝试都失效的无效登录。
对于你的web服务,你可以做一些类似的事情。有一个LOGIN例程,它返回一个GUID,并要求在每个请求时传递GUID。如果它无效,则拒绝该请求。
+1,但FTP通过线路发送未加密的凭证(帐户和密码) – mjn 2009-12-16 18:31:48