How can I bypass Netease defense and use the CSRF worm to continue to brush fans?

1. Since it is a CSRF worm, it must have been a problem on Weibo! Here: POST http://t.163.com/share/retweet HTTP/1.1 Host: t.163.comProxy-Connection: keep-aliveContent-Length: 439 Origin: http://t.163.comUser-Agent : Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.20.1.97 Safari/537.11Content-Type: application/x-www-form-urlencodedAccept: */* Accept-Encoding: gzip, deflate, sdchAccept-Language: zh-CN, zh; q = 0.8Accept-Charset: GBK, UTF-8; q = 0.7 ,*; q= 0.3 Cookie: slightly status = % E6 % AC % A7 % E8 % 81% 94% E5 % B0 % 8F % E7 % BB % 84% E6 % 9C % AB % E8 % BD % AE % E6 % AC % A1 % E6 % 97% A5 % E7 % BB % BC % E8 % BF % B0 % 3A32% E5 % BC % BA % E4 % BA % A7 % E7 % 94 Upload & imageUrl = & method = click & keyfrom = route 163.share 2. the above link is another interface for sending Weibo messages (actually forwarding Weibo messages). Simply put, the status parameter is the published Weibo content, which is mandatory here, I can send the carrier of the csrf worm as a link here to cheat Click! The in_reply_to_status_id parameter is left blank by default, and the source option is optional, indicating where the microblog is forwarded from. The link does not know. If it is left blank, the method and keyfrom parameters are left blank by default! 3. the referer judgment is actually made here, that is, the referer must be 163.com or empty, but not other domains. This means that I can only play with a local single machine! Haha, after a long test, I found that the referer regular expression is incorrect! It only determines whether the domain name contains 163.com, rather than verifying that the root domain name is 163.com. Here, we can construct a subdomain name t.163.com. test. av as a carrier server for Worm Propagation to bypass. Proof of vulnerability: 4. Thank you very much for the subdomain name provided by @ xsjswt. My POC is at the following link: http://t.163.com.xsjswt.3322.org/admin/sessiondata/csrf.html Copy the Code as follows:  Solution:

1. In fact, many problems have been encountered in the middle. If the referer is empty, the defense can be bypassed, so local testing is convenient. However, if the original data packet is not submitted, Weibo can be released normally. However, if it is placed in the POC, the local commit always returns [var updatestatus = 400 ]. Later I knew it was a problem of encoding, the server only recognizes the UTF-8. 2. Since the referer domain name can be changed to t.163.com. test. av, can it be changed to test. av/csrf. php? 163.com? We will consider this as a small detail later! 3. Since the above worms have been implemented, it is easier to brush fans, In the POC Add the following code can be clicked to pay attention to: 4. in terms of defense, we strongly recommend that you change the key request to post! It is better to add tokens for key requests!