SQL Server中,使用Drop Database语句可以删除数据库。
那请问,能不能禁止数据库被删除呢?我有一个WPF桌面应用程序,害怕被反编译
------解决思路----------------------
你的代码中有 Delete、Update 吗?就算你禁止了 Drop Table,那又如何防住别的语句呢?
这个问题不是适合“逐步实现”的,你必须把你的想法深入一些,推翻自己的想法。
------解决思路----------------------
SQL账号没权限就行了
你可以看下数据库的权限是如何配置的
------解决思路----------------------
弄个触发器。
------解决思路----------------------
你对数据库的了解太初级了...
------解决思路----------------------
你的代码中有 Delete、Update 吗?就算你禁止了 Drop Table,那又如何防住别的语句呢?
这个问题不是适合“逐步实现”的,你必须把你的想法深入一些,推翻自己的想法。
别人不知道我的列名,怎么使用其它语句呢?
我自己使用的是存储过程,代码中看不到列名
晕!不知道列名,既然可以对数据库增删改查,难道不会select 出来列名吗?看来你真的没用过数据库sql啊。
------解决思路----------------------
不想大改,就先做好两点:
1、sql账号权限配置,看你样子应该是桌面程序直接连远程接数据库,根本就无需反编译你的软件,直接监听端口截获登录口令即可操作你的数据库,所以登录账户的权限配置变得尤为重要。
2、做好定时备份的维护计划,给端掉了至少还能恢复。
如果要改的彻底一些,就将数据作为服务引用来使用,譬如wcf,桌面程序只需请求服务端的数据对象就行了,只做桌面程序该做的事情。
------解决思路----------------------
可以设置访问数据库的账号的权限
------解决思路----------------------
SQL账号没权限就行了
你可以看下数据库的权限是如何配置的
是的,正解。
------解决思路----------------------
你的代码中有 Delete、Update 吗?就算你禁止了 Drop Table,那又如何防住别的语句呢?
这个问题不是适合“逐步实现”的,你必须把你的想法深入一些,推翻自己的想法。
别人不知道我的列名,怎么使用其它语句呢?
我自己使用的是存储过程,代码中看不到列名
晕!不知道列名,既然可以对数据库增删改查,难道不会select 出来列名吗?看来你真的没用过数据库sql啊。
delete语句用不着列名都。
------解决思路----------------------
配置下权限就好了
------解决思路----------------------
逻辑上讲
禁止 和 权限 都是关联的,如果你想禁止某些事,应该从权限着手吧。
------解决思路----------------------
@ajianchina
[quote ]
直接监听端口截获登录口令即可操作你的数据库
我好奇是怎么做到的。脑洞大开,能不能监听网络游戏的端口然后修改里边的角色参数等等,天啊,越想越兴奋,打盘LOL压压惊先。
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
------解决思路----------------------
@ajianchina
[quote ]
直接监听端口截获登录口令即可操作你的数据库
我好奇是怎么做到的。脑洞大开,能不能监听网络游戏的端口然后修改里边的角色参数等等,天啊,越想越兴奋,打盘LOL压压惊先。
那是因为楼主的服务程序有漏洞,所以才能这样轻易的被破解掉,不是所有网络游戏都这么部署的,或者说,现在的网游根本就没有一款是这么干的.这已经不是传奇的那个时代,在客户端安装个外挂就可以直接影响服务器了
------解决思路----------------------
控制数据库连接账户权限。
------解决思路----------------------
控制数据库连接账户权限。
治标不治本
即使不能使用Drop指令来删除表
但是依然能用delete指令来删掉所有数据
有什么意义?
------解决思路----------------------
@ajianchina
[quote ]
直接监听端口截获登录口令即可操作你的数据库
我好奇是怎么做到的。脑洞大开,能不能监听网络游戏的端口然后修改里边的角色参数等等,天啊,越想越兴奋,打盘LOL压压惊先。
那是因为楼主的服务程序有漏洞,所以才能这样轻易的被破解掉,不是所有网络游戏都这么部署的,或者说,现在的网游根本就没有一款是这么干的.这已经不是传奇的那个时代,在客户端安装个外挂就可以直接影响服务器了
我靠,你牛逼的不得了,你脑洞是得开开了,我真的有点担心你做的那些东西是否给客户考虑过安全性因素,不懂的东西不要瞎bb。那我来说说如何抓吧。
关于TDS的协议分析先看这里:
http://liupx.blogspot.com/2013/05/sql-server-2000.html
TDS的加密算法:
unsigned char *
tds7_crypt_pass(const unsigned char *clear_pass, int len, unsigned char *crypt_pass)
{
int i;
for (i = 0; i < len; i++)
crypt_pass[i] = ((clear_pass[i] << 4)
------解决思路----------------------
(clear_pass[i] >> 4)) ^ 0xA5;
return crypt_pass;
}
解密过程:
将抓取到的密码,搞成十六进制形式的字符串(比如:b6a6c7),每2个字符组成
一个无符号字符,将每个无符号字符同0xA5进行异或,再将高4位同低4位进行互换,即可得到明文。
重点在这里:用wireshark抓包,可以直接看到密码,因为wireshark已经对密码进行了解密。
------解决思路----------------------
想要相对性安全,你就制作证书,否则,轻而易举拿到你的密码,还反编译个毛。
------解决思路----------------------
@ajianchina
[quote ]
直接监听端口截获登录口令即可操作你的数据库
我好奇是怎么做到的。脑洞大开,能不能监听网络游戏的端口然后修改里边的角色参数等等,天啊,越想越兴奋,打盘LOL压压惊先。
那是因为楼主的服务程序有漏洞,所以才能这样轻易的被破解掉,不是所有网络游戏都这么部署的,或者说,现在的网游根本就没有一款是这么干的.这已经不是传奇的那个时代,在客户端安装个外挂就可以直接影响服务器了
我靠,你牛逼的不得了,balabala....
我根本没谈如何抓的问题,也没说不能抓好吧?
我是说,正因为楼主将数据库直接公开到外网上,而客户端直接连接数据库,你才可以这样抓
如果客户端调用的是service,你抓来有毛用?
------解决思路----------------------
想要相对性安全,你就制作证书,否则,轻而易举拿到你的密码,还反编译个毛。
拿到了密码,你也只能用service里提供的方法来提交执行,我没提供drop方法,你执行个我看看?
------解决思路----------------------
sorry! @Z65443344 引用错误,[email protected] 他的帖子,再次sorry!
------解决思路----------------------
用service作为中间件(这个service可以是webapi,webservice等等)
那么你只能提交指令,执行我服务程序提供的函数
我所有函数都要求你传入被操作的数据行信息,而不允许你delete语句不加where条件,你就不能轻易的把我的表给清掉
我根本不提供drop方法,那么你顶多一条一条的调用我的函数去删数据,而根本没有任何办法去drop我的表
因为我的数据服务器在内网里,你根本不能直接操作我的数据库,只能通过外网的服务程序来调用
------解决思路----------------------
sorry! @Z65443344 引用错误,[email protected] 他的帖子,再次sorry!
没啥,可以理解.
对于BenBenBears这种小白来说,突然听到个新鲜名词,就以为是什么高科技了.
科技不是魔法,它都有原理的.黑客也只能抓程序漏洞,正所谓苍蝇不叮无缝蛋
------解决思路----------------------
你们有兴趣可以尝试一下抓包,每个包的前8个字节是固定的:
INT8 INT8 INT16 4 bytes
+----------+-------------+----------+--------------------+
------解决思路----------------------
packet
------解决思路----------------------
last packet
------解决思路----------------------
packet
------解决思路----------------------
unknown
------解决思路----------------------
------解决思路----------------------
type
------解决思路----------------------
indicator
------解决思路----------------------
size
------解决思路----------------------
------解决思路----------------------
+----------+-------------+----------+--------------------+
Fields:
packet type
0x01 TDS 4.2 or 7.0 query
0x02 TDS 4.2 or 5.0 login packet
0x03 RPC
0x04 responses from server
0x06 cancels
0x07 Used in Bulk Copy
0x0F TDS 5.0 query
0x10 TDS 7.0 login packet
0x11 TDS 7.0 authentication packet
0x12 TDS 8 prelogin packet
last packet indicator
0x00 if more packets
0x01 if last packet
packet size
(in network byte order)
unknown?
always 0x00
this has something to do with server to server communication/rpc stuff
跳过前8个字节,下面是TDS7.0登录时,携带用户名密码的报文格式:
TDS 7.0 LOGIN PACKET格式:
byte var type description
---------------------------
0 INT32 total packet size
4 INT8[4] TDS Version
0x00000070 7.0
0x01000071 7.1
0x02000972 7.2 (7.2.9?)
8 INT32 packet size (default 4096)
12 INT8[4] client program version
16 INT32 PID of client
20 INT32 connection id (usually 0)
24 INT8 option flags 1
0x80 enable warning messages if SET LANGUAGE issued
0x40 change to initial database must succeed
0x20 enable warning messages if USE <database> issued
0x10 enable BCP
0x08 use ND5000 floating point format (untested)
0x04 use VAX floating point format (untested)
0x02 use EBCDIC encoding (untested)
0x01 use big-endian byte order (untested)
25 INT8 option flags 2
0x80 enable domain login security
0x40 "USER_SERVER - reserved"
0x20 user type is "DQ login"
0x10 user type is "replication login"
0x08 "fCacheConnect"
0x04 "fTranBoundary"
0x02 client is an ODBC driver
0x01 change to initial language must succeed
26 INT8 0x04 spawn user instance (TDS 7.2)
0x02 XML data type instances are returned as binary XML (TDS 7.2)
0x01 password change requested (TDS 7.2)
27 INT8 0x01 SQL Type: 0 = use default, 1 = use T-SQL (TDS 7.2)
28 INT8[4] time zone (0x88ffffff ???)
32 INT8[4] collation information
36 INT16 position of client hostname (86)
38 INT16 hostname length
40 INT16 position of username
42 INT16 username length
44 INT16 position of password
46 INT16 password length
48 INT16 position of app name
50 INT16 app name length
52 INT16 position of server name
54 INT16 server name length
56 INT16 position of remote server/password pairs
58 INT16 remote server/password pairs length
60 INT16 position of library name
62 INT16 library name length
64 INT16 position of language
66 INT16 language name (for italian "Italiano", coded UCS2)
68 INT16 position of database name
70 INT16 database name length
72 INT8[6] MAC address of client
78 INT16 position of auth portion
80 INT16 NT authentication length
82 INT16 next position (same as total packet size)
84 INT16 0
86 UCS2LE[n] hostname
UCS2LE[n] username
UCS2LE[n] encrypted password
UCS2LE[n] app name
UCS2LE[n] server name
UCS2LE[n] library name
UCS2LE[n] language name
UCS2LE[n] database name
NT Authentication packet
通过抓包可以获取到用户名及加密的密码,然后通过上面的解密方法进行解密,即可得到明文。
------解决思路----------------------
有时候可以有时候不可以
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
总得有个地方存着你的sa用户名和密码吧。
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
总得有个地方存着你的sa用户名和密码吧。
连接数据库又不需要用sa用户密码。
------解决思路----------------------
你的代码中有 Delete、Update 吗?就算你禁止了 Drop Table,那又如何防住别的语句呢?
这个问题不是适合“逐步实现”的,你必须把你的想法深入一些,推翻自己的想法。
别人不知道我的列名,怎么使用其它语句呢?
我自己使用的是存储过程,代码中看不到列名
啥都不会的话,先找本基础的书看看,你的层次太低,还没到达考虑安全性问题的阶段。
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
你确实可以只给一个没有DBA权限的账号,可是这个账号同样要对表进行操作,必须能delete,能update,那么我知道了这个账号的用户名密码,一样可以到你数据库里去搞破坏
而且你说把用户名密码存脑子里?这样可以,但是程序又不能读你的脑子,程序能正常连接数据库?
------解决思路----------------------
如果你只给客户机的用户分配个select权限,那么数据库里根本就不会有数据了
客户机用来连接的用户,好歹得有insert权限和update权限,你的数据库里才可能有数据
否则几万人消费数据,而只有管理员一个人在生成数据?
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
总得有个地方存着你的sa用户名和密码吧。
我在你本机上建个数据库,设置完密码,把密码记到我脑子里,然后屁颠屁颠回家了,你还能把我脑子里的数据读出来?
你的程序需要连数据库的时候还要从你脑子里读出来啊?
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
总得有个地方存着你的sa用户名和密码吧。
连接数据库又不需要用sa用户密码。
你的程序每次都得你上门安装啊?
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
你确实可以只给一个没有DBA权限的账号,可是这个账号同样要对表进行操作,必须能delete,能update,那么我知道了这个账号的用户名密码,一样可以到你数据库里去搞破坏
而且你说把用户名密码存脑子里?这样可以,但是程序又不能读你的脑子,程序能正常连接数据库?
你这个问题就牵扯到一种东西了,这个东西就叫
价值!
只要你把破解你程序的成本,提高到比你程序本身的成本大,这样的问题就不存在了。
还有我只是说不需要sa的密码而已你别激动。
你说的DBA的密码和用户名,你可以做加密加壳之类的手段去处理,对编译后的程序进行混淆之类的手段,那么他破解的成本自然比一个普通的几百块钱的软件要高的多了,你说对不?
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
总得有个地方存着你的sa用户名和密码吧。
连接数据库又不需要用sa用户密码。
你的程序每次都得你上门安装啊?
远程也行啊,他也看不见,不过好的程序,一般都是一键自动安装数据库,自动设置密码的。
防小人只能通过控制破解成本的手段来做了,实在不行就只能 CS版本的了。
------解决思路----------------------
现在仙剑啊那些游戏必须联网才能玩都是有原因的。
------解决思路----------------------
我有一个WPF桌面应用程序,害怕被反编译
如果你的数据库是安装部署在客户机上,那么你没有任何办法防止别人破解这个数据库的,人家随便安装个客户端,就能查看里面所有的内容(当然事先需要从你程序里弄出来sa用户的密码)
如果你的数据库是部署在互联网中的某个服务器上,你就不应该将数据库直接暴露给客户端去操作,而是应该使用webservice之类的技术,让客户端通过服务程序来操作数据库
sa的用户名和密码不一定非要再程序里啊,比如说我用sa给他创建一个授权的账号,在程序里只给他一个账号就行了啊。
总得有个地方存着你的sa用户名和密码吧。
连接数据库又不需要用sa用户密码。
你的程序每次都得你上门安装啊?
远程也行啊,他也看不见,不过好的程序,一般都是一键自动安装数据库,自动设置密码的。
防小人只能通过控制破解成本的手段来做了,实在不行就只能 CS版本的了。
数据库在用户本地,安装程序安装过程不能避免明文提交用户名密码,这个过程安全性非常脆弱。
扯远了,这事和楼主的问题没什么关系。
------解决思路----------------------
SQL账号没权限就行了
你可以看下数据库的权限是如何配置的
正确……
------解决思路----------------------
http://www.2cto.com/Article/200912/43689.html
按SQL权限什么的去查吧……
比如你用账号登录,这个账号拥有访问哪些表的权限,然后对这些表又分别有哪些权限,这都是可以设置的
------解决思路----------------------
给赋一个查询权限即可
------解决思路----------------------
数据库放到服务器,然后对外提供一套接口,客户端程序只能调用这些接口,根本没有数据库的任何信息
------解决思路----------------------
哥,你的问题是能禁止数据库被删吗,最后你还跟我纠结还不是照样select之类的
其实上面好多人都跟你说了,更安全的做法是建立Service端,可以采取的技术有WebService,WCF,WebAPI,甚至一般的handler,Action之类的,当然牵连开来的话,这些服务端又要增加权限方面的判断问题(也是安全性问题,但这个问题跟你的直接数据库方面的安全问题应该不算同一级别的问题了)
------解决思路----------------------
leanring
------解决思路----------------------
分配好SQL账户权限