Skip to content

Commit e344309

Browse files
committedMar 11, 2012
convert more textile to markdown
1 parent fea1bb2 commit e344309

File tree

2 files changed

+12
-12
lines changed

2 files changed

+12
-12
lines changed
 

‎s/plsql.md

+10-10
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ Examples assume the following table structure:
88
accessed_at DATE,
99
superuser NUMBER(1,0)
1010
);
11-
11+
1212
INSERT INTO users VALUES ('janihur', sysdate, 0);
1313
INSERT INTO users VALUES ('petdance', sysdate - 12, 1);
1414
INSERT INTO users VALUES ('albundy', sysdate - 3, 0);
@@ -28,11 +28,11 @@ Static SQL leaves no room for SQL injection.
2828
RETURN v_accessed_at;
2929
END;
3030
/
31-
31+
3232

3333
SELECT user_access('janihur')
3434
AS "JANIHUR LAST SEEN" FROM DUAL;
35-
35+
3636
JANIHUR LAST SEEN
3737
-------------------
3838
2011-08-03 17:11:24
@@ -108,9 +108,9 @@ Instead use bind variables:
108108
Implicit Data Type Conversion Injection
109109
---------------------------------------
110110

111-
Also NLS session parameters (NLS_DATE_FORMAT, NLS_TIMESTAMP_FORMAT, NLS_TIMESTAMP_TZ_FORMAT, NLS_NUMERIC_CHARACTER) can be used to modify or inject SQL statements.
111+
Also NLS session parameters (`NLS_DATE_FORMAT`, `NLS_TIMESTAMP_FORMAT`, `NLS_TIMESTAMP_TZ_FORMAT`, `NLS_NUMERIC_CHARACTER`) can be used to modify or inject SQL statements.
112112

113-
In next example data type conversion takes place when @p_since@ is implicitly converted to a string for concatenation. Note how the value of NLS_DATE_FORMAT affects to the query string in users_since()-function !
113+
In next example data type conversion takes place when `p_since` is implicitly converted to a string for concatenation. Note how the value of `NLS_DATE_FORMAT` affects to the query string in `users_since()` function!
114114

115115
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
116116

@@ -158,10 +158,10 @@ In next example data type conversion takes place when @p_since@ is implicitly co
158158
--------
159159
petdance
160160

161-
The remedy is to set the format modifier explicitly: @to_char(p_since, 'YYYY-MM-DD')@.
161+
The remedy is to set the format modifier explicitly: `to_char(p_since, 'YYYY-MM-DD')`.
162162

163163
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
164-
164+
165165
CREATE OR REPLACE TYPE userlist_t AS TABLE OF VARCHAR2(8);
166166
/
167167

@@ -183,14 +183,14 @@ The remedy is to set the format modifier explicitly: @to_char(p_since, 'YYYY-MM-
183183
END;
184184
/
185185

186-
Now the value of NLS parameter @NLS_DATE_FORMAT@ is ignored during the query.
186+
Now the value of NLS parameter `NLS_DATE_FORMAT` is ignored during the query.
187187

188188
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD"SUPRISE!"';
189189
SELECT COLUMN_VALUE AS "REGULARS" FROM TABLE(users_since(sysdate - 30));
190-
190+
191191
v_query = SELECT username FROM users WHERE superuser = 0 and accessed_at >
192192
'2011-07-04' order by accessed_at desc
193-
193+
194194
REGULARS
195195
--------
196196
janihur

‎s/postgresql.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,7 @@ For such a simple case, you're actually better off writing a pure SQL function:
2424
SELECT accessed_at FROM users WHERE username = $1;
2525
$$;
2626

27-
But sometimes you have to do more complicated things. Perhaps you dynamically add @WHERE@ clause expressions based on input. In such cases, you'll end up using PL/pgSQL's @EXECUTE@ syntax. Here's an example with an SQL injection vulnerability:
27+
But sometimes you have to do more complicated things. Perhaps you dynamically add `WHERE` clause expressions based on input. In such cases, you'll end up using PL/pgSQL's `EXECUTE` syntax. Here's an example with an SQL injection vulnerability:
2828

2929
CREATE OR REPLACE FUNCTION get_users(
3030
p_column TEXT,
@@ -41,7 +41,7 @@ But sometimes you have to do more complicated things. Perhaps you dynamically ad
4141
END;
4242
$$;
4343

44-
Both the @p_column@ and the @p_value@ arguments are vulnerable. The way to avoid this problem is to use the @quote_ident()@ function to quote an SQL identifier (@p_column@ in this case) and @quote_lteral()@ to quote a literal value:
44+
Both the `p_column` and the `p_value` arguments are vulnerable. The way to avoid this problem is to use the `quote_ident()` function to quote an SQL identifier (`p_column` in this case) and `quote_lteral()` to quote a literal value:
4545

4646
CREATE OR REPLACE FUNCTION get_users(
4747
p_column TEXT,

0 commit comments

Comments
 (0)
Please sign in to comment.