Beth Yw SQL Injection a Sut y'i Atal?

Mae SQL injection wedi bod o gwmpas ers diwedd y 1990au ac mae'n dal yn un o'r ffyrdd mwyaf cyffredin i gymeroedd gwe gael eu compromysu. Mae'r byg yn syml: mae ymosodwr yn anfon mewnbwn sy'n cael ei ddehongli fel cod SQL yn lle data plaen, ac mae'r gronfa ddata yn gwneud rhywbeth na fyddai i fod i'w wneud byth.

Sut mae'r ymosodiad yn gweithio mewn gwirionedd

Dychmygwch ffurflen mewngofnodi sy'n adeiladu ymholiad fel hyn yn PHP:

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";

Os nad yw'r ap yn sanitizeio mewnbwn, mae ymosodwr yn teipio admin' -- i faes yr enw defnyddiwr. Mae'r ymholiad yn dod yn:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

Mae'r -- yn rhoi sylw i weddill y llinell, felly mae'r gwiriad cyfrinair byth yn digwydd. Mae hwnnw'n ymgais difregio awdurdodaeth glasurol. Mae ymosodwyr hefyd yn defnyddio UNION SELECT i dynnu data o dablau eraill, neu bentyrru ymholiadau gyda hanner colon i redeg rhywbeth distrywiol fel DROP TABLE users; os yw'r gyrrwr yn caniatáu datganiadau lluosog.

Mae hefyd SQL injection dall, lle nad yw'r ap yn dangos canlyniadau ymholiad yn uniongyrchol. Mae ymosodwyr yn casglu gwybodaeth trwy amseriad (SLEEP(5) yn MySQL) neu ymatebion Booleaidd (a yw'r dudalen yn ymddwyn yn wahanol ar gyfer cyflwr gwir yn erbyn ffug). Mae offer fel sqlmap yn awtomateiddio'r math hwn o echdynnu unwaith y canfyddir paramedr agored i niwed.

Pam bod cysodi llinyn yn y broblem wreiddiol

Mae pob amrywiad o'r ymosodiad hwn yn dod yn ôl i un peth: cymysgu cod a data yn yr un llinyn. Ni all y gronfa ddata wahaniaethu rhwng gwerth legitim a chomposwyd claddu syntacs oherwydd eu bod yn cyrraedd yn yr un sianel. Mae dianc dyfynodau yn helpu mewn rhai achosion ond mae'n friws — amcodiadau gwahanol, chwistrellio ail-drefn (data wedi'i storio unwaith, yna ail-ddefnyddio'n anniogel yn ddiweddarach), a rhyfeddodau penodol y gyrrwr i gyd yn creu llwybrau fforddio. Mae dianc yn glytiad, nid ateb.

Ymholiadau parameteried yw'r ateb go iawn

Yr ateb yw gwahanu cod SQL o ddata defnyddiwr ar lefel y gyrrwr, gan ddefnyddio ymholiadau parameteried (a elwir hefyd yn ddatganiadau paratoi). Mae'r cronfa ddata yn cael strwythur yr ymholiad yn gyntaf, yna'n rhwymo gwerthoedd yn ddiweddarach, felly ni all mewnbwn defnyddiwr byth newid ystyr yr ymholiad.

Yn Python gyda psycopg2:

cur.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))

Yn Node.js gyda mysql2:

connection.execute('SELECT * FROM users WHERE username = ? AND password = ?', [username, password]);

Yn Java gyda JDBC:

PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?");
stmt.setString(1, username);
stmt.setString(2, password);

Notwch y patrwm: mae lleolwyr (%s, ?) yn dal y lle ar gyfer data, ac mae'r gwerthoedd gwirioneddol yn cael eu pasio ar wahân. Dim cysodi llinyn, dim dianc llaw-angen. Mae hyn yn gweithio ar gyfer y rhan fawr o ymholiadau y byddwch chi'n eu hysgrifennu mewn ap arferol.

Beth am enwau tabl neu golofn ddynamig?

Mae paramedriad yn trin gwerthoedd ond nid adnabyddwyr — ni allwch rwymo enw tabl fel paramedr. Os yw angen i'ch ap ddewis tabl yn ddynamig (anaml, ac yn aml yn arwydd dylunio), gweynebwch y gwerthoedd caniateir yn erbyn rhestr galed yn lle ymddiried mewn mewnbwn defnyddiwr yn uniongyrchol:

allowed_tables = {'orders', 'invoices', 'customers'}
if table_name not in allowed_tables:
    raise ValueError("Invalid table")

Bydded byth yn adeiladu enwau adnabyddwyr drwy fformadu llinyn o fewnbwn defnyddiwr, hyd yn oed gyda dianc.

Amddiffynfeydd haenedig y tu hwnt i'r ymholiad ei hun

Ymholiadau parameteried yw'r rheolaeth gynradd, ond mae ychydig o bethau eraill yn bwysig:

• Preintiliwch lleiaf ar y cyfrif cronfa ddata. Ni ddylai defnyddiwr DB yr ap fod â DROP, ALTER, neu fynediad i schemâu anghysylltiedig. Os yw chwistreliad yn llithro trwodd, cyll preintiliwch cyfyngedig y niwed.
• Mae ORMs yn helpu yn rhagosodedig. Mae ORM Django, SQLAlchemy, a Hibernate i gyd yn paramedriad ymholiadau'n awtomatig pan fyddwch chi'n defnyddio eu dulliau adeiladu ymholiad safonol. Mae'r risg yn ailymddangos pan fydd datblygwyr yn rhedeg i SQL crai neu'n defnyddio galwadau .extra()/text() gyda rhyngosodiad llinyn — felly archwilwch y mannau hynny'n benodol.
• Mae dilysu mewnbwn yn haen ail, nid amnewid. Mae gwirio bod maes e-bost yn edrych fel e-bost yn ymarfer da, ond nid yw'n stopio chwistreliad ohono'i hun — mae ymosodwyr yn canfod llwythi creadigol sy'n dal yn pasio dilysu llac.
• Gall WAF ddal patrymau ymosodiad hysbys, ond haen ganfod ydyw, nid ateb ar gyfer y cod blaenoriaethol.

Profi eich cod eich hun ar gyfer y byg hwn

Rhedwch eich ymholiadau drwy ddeclyn dadansoddiad statig (Bandit ar gyfer Python, Semgrep gyda setiau rheolau chwistreliad SQL) fel rhan o CI. Ar gyfer profi llaw-angen, ceisiwch chwistrellu dyfynod sengl (') i bob maes mewnbwn a gwyliwch am negeseuon gwall SQL yn gollwng yn yr ymateb — dyna yn aml yr arwydd cyntaf nad yw ymholiad yn baramedriad.

Os ydych chi am fynd yn ddyfnach ar hyn, mae trac Web Security Korra Studio yn trin chwistreliad ochr yn ochr â XSS a fforddio awdurdodaeth, ac mae'r segmentau Cronfeydd Ddata yn cerdded trwy batrymau dylunio ymholiad sy'n osgoi'r dosbarth byg hwn yn llwyr.