0. About World Laboratory of Bugtraq 2
1. Identification of safety notes
2. Adding entries
3. Description specification of the note details
4. Common Vulnerabilities and Exposures (CVE)
5. Common Weakness Enumeration (CWE)
 0. About World Laboratory of Bugtraq 2
(WLB2) World Laboratory of Bugtraq is a huge collection of information on data communications safety. Its main objective is to inform about errors in various applications. The WLB tolerance does not exclude information on errors in a configuration or other entries of this kind of dangerous operations character. One of the basic foundations of "World Laboratory of Bugtraq" is interaction with users. Each safety note, can be reported, and then verified by the CXSecurity. The second version of the database WLB2, introduces many changes from the previous version WLB1, acting on pages securityreason.com. Adding value for CVE CWE CVSS-defined entries in the database or add a new status of 'exploit' is not the only innovations in the next version of World Laboratory of Bugtraq (WLB2). We wish you a good time.
I do not believe in democracy ...
CXSECURITY Team == One person!
Support an independent blog.
Let our enemy will be your enemy.
Peace and respect for all.
1. Identification of safety notes
Determining the entry number in the WLB base is performed on the basis of assigning an individual number to every entry, according to the following pattern
WLB-YYYYMMNNNN |
where::
| YYYY |
- the year in which the given data were entered into the base |
| MM |
- analogically, the month |
| NNNN |
- the number which identifies a given entry in the base |
|
An example number WLB
WLB-2000111234
which proves that a given entry was added to the base in November, 2000. The last numbers denote the ID number the given vulnerability in the given year and month. In order to refer to a WLB number, one is allowed to use the following syntax:
 https://cxsecurity.com/issue/[the number WLB]
or use a search engine https://cxsecurity.com/search/
2. Adding entries
A WLB list has no limitations concerning information on data communications safety. Everyone is allowed to send a proposal of a note to the list. Just use this form or email submit@cxsecurity.com Safety notes can be added automatically by moderators.
3. Description specification of the note details
| Topic |
defines the topic of an vulnerability, containing general information about the software and the kind of an error. |
| Date |
defines the year, the month, the day. The aim of this value is to inform the user when a given entry was officially made accessible. It is analogical with the Updated field, with a small difference referring to the last accepted change in a given note. |
| Credit |
defines the person who is the author of the given vulnerability as presented and described in the WLB safety note. |
| Risk |
is a variable defining the total threat which can result from a given item of information. The criterion marking one of three levels, it is possible to use that information as well as the number of machines with the defective code. |
| Remote/Local |
define the manner of the vulnerability utilization as each machine can be attacked form the outside or from the internal level. These are quite important parameters since they tell us about the tactical utilization of the given information. |
| History |
defines which changes were made into a given note, by whom and when. The dates define the time when that happened. |
| References |
is a field containing references to further information on a given vulnerability. One is permitted to enter references leading to the authors' web sites. |
| Status |
defines a part of the given information. The classification occurs on four levels:
| Bug |
this informs that a note refers to the vulnerability present in a given application. Each item of information with this status states that a given vulnerability has taken place or is taking place at present. |
| Bogus |
each item of information with this status has a task to negate the existence of the false information. The use of this status is permitted in the case of a mistake or in order to countercheck the expansion of unnecessary panic. |
| Trick |
all information with this status are of the character which proves a lack of cohesion among programmers, a possibility of an attack because of a bad configuration, a presentation of a new aspect of avoiding protections or (unnecessary) philosophical disputes on the theory of machine safety. |
| Exploits |
this informs that a note refers to the exploit or PoC (Proof of Concept) present in a given application. |
|
| CVE |
are unique, common identifiers for publicly known information security vulnerabilities. |
| CWE |
is a formal list of software weakness types created to serve as a common language for describing software security weaknesses in architecture, design, or code. |
4. Common Vulnerabilities and Exposures (CVE)
A list of standardized names for vulnerabilities and other information security exposures - CVE aims to standardize the names for all publicly known vulnerabilities and security exposures. CVE is:
- One standardized name for each vulnerability or exposure
- The way to interoperability and better security coverage
- A basis for evaluation among tools and databases
- Industry-endorsed via the CVE Editorial Board and CVE-compatible products and services
- Free to the public on the CVE Web site The CVE ID of a vulnerability, if available, is displayed in the "Details" tab of the WLB2 Database. Users can search the entire vulnerability database for vulnerability records matching a particular CVE Identifiers:
http://cxsecurity.com/cve/
In order to refer to a CVE number, one is allowed to use the following syntax:
http://cxsecurity.com/cve/[CVE-YYYY-NNNN]
To see only security alerts related with CVE:
http://cxsecurity.com/cvelist/
5. Common Weakness Enumeration (CWE)
Common Weakness Enumeration (CWE) is a formal list of software weakness types created to - Serve as a common language for describing software security weaknesses in architecture, design, or code.
- Serve as a standard measuring stick for software security tools targeting these weaknesses.
- Provide a common baseline standard for weakness identification, mitigation, and prevention efforts.
| CWE-89 |
SQL injection attacks are another instantiation of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. See examples... |
| CWE-79 |
Cross-site scripting (XSS) weakness occurs when dynamically generated web pages display input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. If successful, Cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. See examples... |
| CWE-119 |
A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. See examples... |
| CWE-98 |
A PHP product uses "require" or "include" statements, or equivalent statements, that use attacker-controlled data to identify code or HTML to be directly processed by the PHP interpreter before inclusion in the script. See examples... |
| CWE-548 |
A directory listing is innapropriately exposed yielding potentially sensitive information to attackers. See examples... |
| CWE-352 |
The web product does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request. CSRF is multi-channel: 1. Attacker-to-victim (injection; external or internal channel) 2. Victim-to-server (activation; internal channel) See examples... |
In order to refer to a CWE number, one is allowed to use the following syntax:
http://cxsecurity.com/cwe/[CWE-NNN]
CWE Dictionary is available at:
http://cxsecurity.com/allcwe/
To see only security alerts related with CWE:
http://cxsecurity.com/cwelist/
To find CWE, use search engine:
http://cxsecurity.com/search/
| 