19.12.2012 Views

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Safeguard Catalogue - Organisation Remarks<br />

____________________________________________________________________ .........................................<br />

S 2.134 Guidelines for database queries<br />

Initiation responsibility: Head of <strong>IT</strong> Section, <strong>IT</strong> Security Management<br />

Implementation responsibility: Application developer<br />

<strong>The</strong> relational database language SQL (Standard Query Language) is a<br />

standardised international language for relational database systems; it has<br />

found widespread use and is implemented in most database management<br />

systems. SQL can be used to modify data (UPDATE, INSERT, DELETE),<br />

manipulate database objects (CREATE, ALTER, DROP) and request<br />

information (SELECT). To ensure secure operation of a database, the<br />

following basic guidelines should be observed when making database queries:<br />

- SQL queries should be formulated as precisely as possible. This applies<br />

particularly to SQL queries generated from applications. For example, the<br />

SQL statement<br />

SELECT * FROM WHERE <br />

inevitably leads to errors or even causes the related application to crash if<br />

the table scheme has been modified (addition or deletion of fields, or<br />

changes in the field sequence).<br />

- Fields should always be specified explicitly. This ensures that the data is<br />

made available in the awaited sequence, and that only the information<br />

which is actually required is selected, for instance.<br />

Example:<br />

A table consists of the following fields (with the related data types):<br />

Article number NUMBER(10)<br />

Net price NUMBER(10,2)<br />

Article designation VARCHAR(30)<br />

Intended use VARCHAR(200)<br />

A new field titled "Order number" and having type NUMBER(8) is added.<br />

To optimise memory utilisation, the field is located at the second position<br />

of the table, not at the end. <strong>The</strong> new table then appears as follows:<br />

Article number NUMBER(10)<br />

Order number NUMBER(8)<br />

Net price NUMBER(10,2)<br />

Article designation VARCHAR(30)<br />

Intended use VARCHAR(200)<br />

In the worst case, a SELECT-* statement issued from an application would<br />

now lead to a crash, as the data is selected automatically in the specified<br />

field sequence. <strong>The</strong> example shown above not only poses the problem of<br />

the table having been extended by one field (whose data are selected<br />

additionally), but also of the field sequence having been modified, so that<br />

the data is no longer selected in the original order. This leads inevitably to<br />

type conflicts and, possibly, to program failure.<br />

____________________________________________________________________ .........................................<br />

<strong>IT</strong>-<strong>Baseline</strong> <strong>Protection</strong> <strong>Manual</strong>: Oktober 2000

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!