0day.today - Biggest Exploit Database in the World.
![](/img/logo_green.jpg)
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earnGOLD
Administration of this site uses the official contacts. Beware of impostors!
![We DO NOT use Telegram or any messengers / social networks!](/img/no_telegram_big.png)
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
The Everything Development System <= Pre-1.0 SQL Injection Vuln
=============================================================== The Everything Development System <= Pre-1.0 SQL Injection Vuln =============================================================== Application: The Everything Development System Version(s): <= Pre-1.0 (current version at time of release) Author: sub Released: 2/1/2008 There exists a vulnerability in The Everything Development Engine that allows a user to inject their own SQL to modify a SELECT query, leading to information disclosure, XSS, or privilege escalation. What's more, passwords are stored in the database as plaintext, making user accounts very easily compromised. In some versions of the software I have encountered, the following proof of concept will display a corresponding username and password in the "core" field and "reputation" field on the page, respectively. Proof of Concept: http://path.to/cms/index.pl?node_id=0/**/UNION/**/SELECT/**/null,101,null,1,null,null,passwd,null,null,nick,null/**/FROM/**/user/**/WHERE/**/nick/**/!%3d/**/''/**/%23 In other, probably more recent versions, a 13-column query is required or the UNION. What does not change, is that of all of the various versions I've encountered, all are vulnerable to SQL injection. The ideal fix would be to ensure that the 'node_id' request variable is the appropriate data-type (signed int) before passing it as part of a SQL query. Vendor Status: A private ticket was created on the vendors Bug Tracker page prior to this release. However, I have decided to release this vulnerability without a reply from the vendor as the Bug Tracker, and development project, seemed to be 'abandonded.' # 0day.today [2024-07-07] #