You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: s/plsql.md
+10-10
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ Examples assume the following table structure:
8
8
accessed_at DATE,
9
9
superuser NUMBER(1,0)
10
10
);
11
-
11
+
12
12
INSERT INTO users VALUES ('janihur', sysdate, 0);
13
13
INSERT INTO users VALUES ('petdance', sysdate - 12, 1);
14
14
INSERT INTO users VALUES ('albundy', sysdate - 3, 0);
@@ -28,11 +28,11 @@ Static SQL leaves no room for SQL injection.
28
28
RETURN v_accessed_at;
29
29
END;
30
30
/
31
-
31
+
32
32
33
33
SELECT user_access('janihur')
34
34
AS "JANIHUR LAST SEEN" FROM DUAL;
35
-
35
+
36
36
JANIHUR LAST SEEN
37
37
-------------------
38
38
2011-08-03 17:11:24
@@ -108,9 +108,9 @@ Instead use bind variables:
108
108
Implicit Data Type Conversion Injection
109
109
---------------------------------------
110
110
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.
112
112
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!
114
114
115
115
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
116
116
@@ -158,10 +158,10 @@ In next example data type conversion takes place when @p_since@ is implicitly co
158
158
--------
159
159
petdance
160
160
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')`.
162
162
163
163
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
164
-
164
+
165
165
CREATE OR REPLACE TYPE userlist_t AS TABLE OF VARCHAR2(8);
166
166
/
167
167
@@ -183,14 +183,14 @@ The remedy is to set the format modifier explicitly: @to_char(p_since, 'YYYY-MM-
183
183
END;
184
184
/
185
185
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.
187
187
188
188
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD"SUPRISE!"';
189
189
SELECT COLUMN_VALUE AS "REGULARS" FROM TABLE(users_since(sysdate - 30));
190
-
190
+
191
191
v_query = SELECT username FROM users WHERE superuser = 0 and accessed_at >
Copy file name to clipboardexpand all lines: s/postgresql.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,7 @@ For such a simple case, you're actually better off writing a pure SQL function:
24
24
SELECT accessed_at FROM users WHERE username = $1;
25
25
$$;
26
26
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:
28
28
29
29
CREATE OR REPLACE FUNCTION get_users(
30
30
p_column TEXT,
@@ -41,7 +41,7 @@ But sometimes you have to do more complicated things. Perhaps you dynamically ad
41
41
END;
42
42
$$;
43
43
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:
0 commit comments