可以采用以下几点措施。
蠡县ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！
（1）在用户数据进入数据库之前使用addslashes()函数过滤，可以进行一些字符的转义，并过滤掉可能引起数据库问题的字符。可以使用stripslashes()将数据返回到原始形式。
（2）在php.infi中开启magic_quotes_gpc和magic_quotes_runtime指令。它们可以自动的添加和过滤斜杠，前者主要用于格式化GET，POST，和cookie变量，后者用于过滤进出数据库的数据。
（3）当在system()或者exex()函数中使用用户输入数据作为参数时，必须使用escapeshellcmd()。用来避免怀有恶意的用户强迫系统运行某些命令。
（4）可以使用stip_tags()从一个字符串中去掉HTML和PHP标记，这样可以避免用户将恶意节本植入到用户的数据中。
（5）可以使用htmlspecialchars()，可以将字符专程它们的HTML等价实体。例如，将被转换成lt; ,该函数可以将任何脚本转换成无害的字符。
总之，在使用用户的数据时，一定要小心，原则即是不要相信用户输入的任何数据，必须要进行过滤和转换。
1、PHP动态语言执行过程：拿到一段代码后，经过词法解析、语法解析等阶段后，源程序会被翻译成一个个指令（opcodes）,然后ZEND虚拟机顺次执行这些指令完成操作。PHP本身是用C实现的，因此最终调用的也是C的函数，实际上，我们可以把PHP看做一个C开发的软件。
2、PHP的4层运行体系：
（1）Zend引擎：Zend整体用纯C实现，是PHP的内核部分，他将PHP代码翻译（词法、语法解析等一系列编译过程）为可执行opcode的处理并实现相应的处理方法、实现了基本的数据结构（如：hashtable、OO）、内存分配机制及管理、提供了相应的api方法供外部调用，是一切的核心，所有的外围功能均围绕Zend实现。
（2）Extensions：围绕着Zend引擎，extensions通过组件式的方式提供各种基础服务，我们常见的各种内置函数（array系列）、标准库等都是通过extension来实现，用户也可以根据需要实现自己的extension的典型应用）。
（3）Sapi：Sapi全称ServerApplicationProgrammingInterface，也就是服务端应用编程接口，Sapi通过一系列钩子函数，使得PHP可以和外围交互数据，这是PHP非常优雅和成功的设计，通过sapi成功的将PHP本身和上层应用解耦隔离，PHP可以不再考虑如何针对不同应用进行兼容，而应用本身也可以针对自己的特点实现不同的处理方式。
（4）上层应用：这就是我们平时编写的PHP程序，通过不同的spai方式得到各种各样的应用模式，如何通过webserver实现web应用、在命令行下已脚本方式运行等等。
我现在的用法是:\x0d\x0a1、每个人登录的时候会生成一个随机码(随机码保存在数据库中)；\x0d\x0a2、客户端cookies不保存用户名，只保存随机码；\x0d\x0a3、账号在任何的地方登录时便会执行第一二部，之前的登录就会失效；\x0d\x0a4、就这样就实现了你的功能；\x0d\x0a\x0d\x0a扩展:\x0d\x0a5、可以设置网页最后更新的时间，并且超过一定的时间后就过期；\x0d\x0a6、随机码要长一点才不会重复，我现在用的64进制32位，这样几乎不可能重复；\x0d\x0a7、另外客户端不保存用户名和密码只存存随机码相对来说安全性也要高些；
楼主你可以考虑MYSQL的事务处理功能。
一般来说，事务是必须满足4个条件（ACID）
原子性（Autmic）：事务在执行性，要做到“要么不做，要么全做！”，就是说不允许事务部分得执行。即使因为故障而使事务不能完成，在rollback时也要消除对数据库得影响！
一致性（Consistency）：事务得操作应该使使数据库从一个一致状态转变倒另一个一致得状态！就拿网上购物来说吧，你只有即让商品出库，又让商品进入顾客得购物篮才能构成事务！
隔离性（Isolation）：如果多个事务并发执行，应象各个事务独立执行一样！
持久性（Durability）：一个成功执行得事务对数据库得作用是持久得，即使数据库应故障出错，也应该能够恢复！
说白了就是某一个用户进行兑换操作的时候，就把对应的数据表锁定死，只有等操作完成后才解锁。
首先一个是在修改用户资料页面怎样判断当前登陆的是哪个用户？
----答：你在数据库里面加个字段，记录用户的类型的，然后登陆的时候用 cookie 或者 sessssion 记录他的用户类型。如 $_session['type']='admin'
然后就是，其实cookie很安全至少不像传说中的那样危险，这个你可以百度下别人的文章，一般情况下cookie是很难被修改的，所以考虑cookie的安全是必要的但是太过分了就没必要了。
其次，session保存在服务器不假，每个session都有一个唯一的id 你打印 session数组久知道，程序可以通过那个id判断session的所有者。
在这个互联网高度发达的时代，许多应用的用户动辄成百上千万，甚至上亿。为了支持海量用户的访问，应用服务器集群这种水平扩展的方式是最常用的。这种情形下，就会涉及到许多单机环境下完全不需要考虑的问题，这其中session的创建、共享和存储是最常见之一。
在单机环境中，Session的创建和存储都是由同一个应用服务器实例来完成，而存储也仅是内存中，最多会在正常的停止服务器的时候，把当前活动的Session钝化到本地，再次启动时重新加载。
而多个实例之间，Session数据是完全隔离的。而为了实现Session的高可用，多实例间数据共享是必然的，下面我们以Redis 的SessionManager实现多Tomcat实例Session共享的配置为例，我们来梳理下一般session共享的流程：
添加具体要使用的manager的Jar文件及其依赖
redis session manager依赖jedis, commons-pool, commons-pool2
对应版本的redis session manager的jar文件
在TOMCAT_HOME/conf/context.xml中增加如下配置
Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" /
Manager className="com.radiadesign.catalina.session.RedisSessionManager"
host="localhost"
port="6379" database="0"
maxInactiveInterval="30" /
其中host和port等替换为对应的配置信息
启动多个Tomcat实例，以自带的examples应用为例进行验证
访问examples应用的servlets/servlet/SessionExample，
在页面中添加数据到session中，并查看页面上对应的session信息
访问另一个实例上相同应用的页面，查看session信息，两者应该是一致的
使用redis-cli查看redis中存储的对应数据，相应的sessionId对应的数据已经保存了下来
以上是一个基本的配置过程，而在这些配置与验证的步骤中，第二步是核心逻辑实现。 前面的文章，曾介绍过Tomcat的Valve，在请求处理时，Pipeline中的各个Valve的invoke方法会依次执行。Tomcat的AccessLogValve介绍
此处的session处理，就是以一个自定义Valve的形式进行的。关于Session的文章，前面也写过几篇，会附在结尾处。
以下是RedisSessionhandlerValve的invoke方法，我们看，主要是在Valve执行后进行Session的存储或移除。
public void invoke(Request request, Response response) {
try {
getNext().invoke(request, response);
} finally {
final Session session = request.getSessionInternal(false);
storeOrRemoveSession(session);
manager.afterRequest();
}
}
而session的保存和移除又是通过manager执行的。 manager.save(session); manager.remove(session);
这里，manager就是前面定义的RedisSessionManager。默认单实例情况下，我们使用的都是StandardManager，对比一下两者，标准的Manager对于session的创建和删除，都会调到其父类ManagerBase中相应的方法，
public void add(Session session) {
sessions.put(session.getIdInternal(), session);
int size = getActiveSessions();
if( size maxActive ) {
synchronized(maxActiveUpdateLock) {
if( size maxActive ) {
maxActive = size;
}
}
}
}
public void remove(Session session, boolean update) {
if (session.getIdInternal() != null) {
sessions.remove(session.getIdInternal());
}
}
我们来看，由于其只保存在内存的Map中protected MapString, Session sessions = new
ConcurrentHashMap()，每个Tomcat实例都对于不同的map，多个实例间无法共享数据。
对应到RedisSessionManager对于session的处理，都是直接操作redis，基本代码是下面这个样：
public void save(Session session) throws IOException {
Jedis jedis = null;
Boolean error = true;
try {
RedisSession redisSession = (RedisSession) session;
Boolean sessionIsDirty = redisSession.isDirty();
redisSession.resetDirtyTracking();
byte[] binaryId = redisSession.getId().getBytes();
jedis = acquireConnection();
if (sessionIsDirty || currentSessionIsPersisted.get() != true) {
jedis.set(binaryId, serializer.serializeFrom(redisSession));
}
currentSessionIsPersisted.set(true);
jedis.expire(binaryId, getMaxInactiveInterval());
} }
移除时的操作是这样的
public void remove(Session session, boolean update) {
Jedis jedis = null;
Boolean error = true;
log.trace("Removing session ID : " + session.getId());
try {
jedis = acquireConnection();
jedis.del(session.getId());
error = false;
} finally {
if (jedis != null) {
returnConnection(jedis, error);
}
}
}
而此时，多个Tomcat实例都读取相同的Redis，session数据是共享的，其它实例的初始请求过来时，由于会执行findSession的操作，此时会从Redis中加载session，
public Session findSession(String id) throws IOException {
RedisSession session;
if (id == null) {
session = null;
currentSessionIsPersisted.set(false);
} else if (id.equals(currentSessionId.get())) {
session = currentSession.get();
} else {
session = loadSessionFromRedis(id); // 看这里，会从redis中load
if (session != null) {
currentSessionIsPersisted.set(true);
}
}
currentSession.set(session);
currentSessionId.set(id);
return session;
}
从而可以保证在一个实例被切换后，另外的实例可以继续响应同一个session的请求。
以上即为Redis实现session共享高可用的一些关键内容。有兴趣的朋友可以看下通过Memcached实现高可用，也是这个原理。顺着这个思路，如果你有将Session存储在其它地方的需求时，完全可以写一个出来，自己动手，丰衣足食。
总结一下，我们是通过自定义的Valve来实现请求后session的拦截，同时，使用自定义的SessionManager,来满足不同的session创建与存储的需求。而至于是存储在Redis/Memcached中，还是存储在DB中，只是位置的区别。原理，是一致的。