There have been news stories about websites getting hacked, and the hackers making off with lots of customer/employee/third-party information.  How do hackers normally do this?

In the younger days of the internet, most sites were vulnerable to an exploit called SQL injection.  SQL is a programming language associated with a type of database.  A database is what actually stores information that website visitors put into the website so they can use the site how they want.  Most sites these days have a database they rely on to control--among other things--how users can access the site's services.  Other sites use flat files or databases stored in flat files, such as those created and managed by Microsoft Access, which come with their own problems, but we'll stick with actual databases here.  

For example, whenever you sign up to use the services of a website, the information you put into the account setup page is then stored in a database.  You are actually telling the web application what information to put into the database by inputting values into the page's input fields, then clicking the "Submit" button.  The page will ask you for things such as a username and password, maybe your name and birthdate, and whatever else the web site needs to build a profile of you.  Depending on the site, it may even ask a user for their credit card details and other financial information.  The web application updates the database by using an application account to log into the database, then either inserting new information into the database, or updating the information already in the database so it can be used later.  When you then log into the website later, you input your username and password you set up when you created your account, and the application attempts to retrieve the information from the database, checking to see if what you put in is the same as what is in the database, then it gives you access to the services available to your account.

Where it will sometimes go wrong is when the web application is told to get data from the database that the application is not supposed to return to a normal user.  This is accomplished by knowing what the application expects the user to put into a certain input field, knowing how the application's queries to the database are written, and knowing that either the application administrator or the database administrator did not limit the web application's access to the database--giving the application access to everything in the database, instead of limiting the application for just the tables and permissions it needs.

Here is a simplistic example.  A user wants to log into a web site.  The user puts in the username and password for his or her account.  The web application usually then logs into the database and performs a query--SELECT \* FROM users where username=user1 and password=password2.  If a valid row is returned, the user gets logged into the site, is given the permissions the account is set up with, and continues the session.  If no data is returned, the user is deposited on the "Wrong password" page.  Seems logical, right?

Now, say a hacker logs into the same website, but he or she does not put in a valid username--the hacker simply puts in an asterisk in the username and password fields.  Depending on how the application is written, it may log into the database and perform this query instead--SELECT \* FROM users where username=\* and password=\*  (reddit may have a formatting problem with that).  Depending on how the application and database are set up, the hacker may get a database error, he or she may get logged into the first account set up in the web site (which often is the admin account), or the application may return a list of user accounts, complete with usernames and passwords (and maybe credit card numbers, expiration dates, etc).  You can see how this may be a problem.  There are other methods of tricking the application into giving up data, using a similar method of SQL injection, but the result is often the same--either someone has acquired more information than they need, or someone is just given the keys to the kingdom.

To combat this problem, some websites have written the database queries their applications use to get data from the database so that queries do not return so much data, which in some cases results in a tiny performance boost.  For example, a SELECT userid FROM users where username=\* and password=* may simply return a list of userids instead of the entire users table--but some applications will allow the hacker to be logged into the first account in the database--the admin account, usually.  Also, most sites do not save account passwords to their databases in readable form--they run the passwords through an encryption algorithm before saving them as hashes in the database--instead of "password2", there may be a long string of random characters and numbers in its place.  So, a user logs into the database with "password2", the application immediately puts the user's input through the encryption, and if it matches the resulting hash in the database, the user is allowed access to the account.  However, in poorly-written applications, this still results in an unauthorized user logged into someone else's account.  In an effort to stop this, most sites today use code which scrubs most special characters out of input fields to guard against sql injection.  So, when a hacker goes to put asterisks in an input field, the hacker presses Submit, the application immediately scrubs the asterisks out, and the hacker is left with either a database error, or--on well-written applications--deposited on a Wrong Password page.  This is normally called "sanitizing" the input.  Most of the sites you will browse have this feature in the application, but some sites will not.  Best to not try and find out.

So, basically, you're not allowed to have special characters in the password field on some sites because the website owners don't want other people getting access to your information, so they run most of their inputs through a scrubber that stops what used to be a very prolific exploit.
වෙබ් අඩවි අනවසරයෙන් ඇතුළුවීම සහ හැකර්වරුන් ගනුදෙනුකරුවන්/සේවක/තුන්වන පාර්ශ්ව තොරතුරු රැසක් සමඟ ප්‍රවෘත්ති වාර්තා වී ඇත. හැකර්වරුන් සාමාන්‍යයෙන් මෙය කරන්නේ කෙසේද? අන්තර්ජාලයේ තරුණ දිනවල, බොහෝ වෙබ් අඩවි SQL එන්නත් ලෙස හැඳින්වෙන සූරාකෑමකට ගොදුරු විය. SQL යනු දත්ත සමුදා වර්ගයක් හා සම්බන්ධ ක්‍රමලේඛන භාෂාවකි. දත්ත සමුදායක් යනු වෙබ් අඩවි නරඹන්නන් වෙබ් අඩවියට ඇතුළත් කරන තොරතුරු ඇත්ත වශයෙන්ම ගබඩා කරන අතර එමඟින් ඔවුන්ට අවශ්‍ය ආකාරයට වෙබ් අඩවිය භාවිතා කළ හැකිය. මේ දිනවල බොහෝ වෙබ් අඩවි වල ඔවුන් පාලනය කිරීමට රඳා පවතින දත්ත ගබඩාවක් ඇත - වෙනත් දේ අතර - පරිශීලකයින්ට වෙබ් අඩවියේ සේවාවන් වෙත ප්‍රවේශ විය හැකි ආකාරය. අනෙකුත් වෙබ් අඩවි ඔවුන්ගේම ගැටළු සමඟ එන Microsoft Access මගින් සාදන ලද සහ කළමනාකරණය කරන ලද පැතලි ගොනු හෝ පැතලි ගොනු වල ගබඩා කර ඇති දත්ත සමුදායන් භාවිතා කරයි, නමුත් අපි මෙහි සත්‍ය දත්ත සමුදායන් සමඟ රැඳී සිටිමු. උදාහරණයක් ලෙස, ඔබ වෙබ් අඩවියක සේවාවන් භාවිතා කිරීමට ලියාපදිංචි වන සෑම විටම, ඔබ ගිණුම් සැකසුම් පිටුවට ඇතුළත් කරන ලද තොරතුරු දත්ත සමුදායක ගබඩා වේ. පිටුවේ ආදාන ක්ෂේත්‍රවලට අගයන් ඇතුළත් කර, පසුව &quot;ඉදිරිපත් කරන්න&quot; බොත්තම ක්ලික් කිරීමෙන් දත්ත සමුදායට ඇතුළත් කළ යුතු තොරතුරු මොනවාදැයි ඔබ සැබවින්ම වෙබ් යෙදුමට කියයි. පරිශීලක නාමයක් සහ මුරපදයක්, සමහර විට ඔබේ නම සහ උපන් දිනය, සහ වෙබ් අඩවියට ඔබේ පැතිකඩක් ගොඩනගා ගැනීමට අවශ්‍ය වෙනත් දේවල් වැනි දේවල් සඳහා පිටුව ඔබෙන් අසනු ඇත. වෙබ් අඩවිය මත පදනම්ව, එය පරිශීලකයෙකුගෙන් ඔවුන්ගේ ක්‍රෙඩිට් කාඩ් විස්තර සහ වෙනත් මූල්‍ය තොරතුරු ඉල්ලා සිටිය හැක. වෙබ් යෙදුම දත්ත සමුදායට ලොග් වීමට යෙදුම් ගිණුමක් භාවිතා කිරීමෙන් දත්ත සමුදාය යාවත්කාලීන කරයි, ඉන්පසු එක්කෝ නව තොරතුරු දත්ත ගබඩාවට ඇතුළු කිරීම හෝ දැනටමත් දත්ත ගබඩාවේ ඇති තොරතුරු යාවත්කාලීන කිරීමෙන් පසුව එය භාවිතා කළ හැකිය. ඔබ පසුව වෙබ් අඩවියට ලොග් වූ විට, ඔබ ඔබේ ගිණුම නිර්මාණය කරන විට ඔබ විසින් සැකසූ ඔබගේ පරිශීලක නාමය සහ මුරපදය ඇතුළත් කරන අතර, යෙදුම දත්ත සමුදායෙන් තොරතුරු ලබා ගැනීමට උත්සාහ කරයි, ඔබ ඇතුළත් කළ දේ සමානද යන්න පරීක්ෂා කරයි. දත්ත සමුදාය තුළ, එය ඔබගේ ගිණුමට ලබා ගත හැකි සේවාවන් වෙත ප්රවේශය ලබා දෙයි. එය සමහර විට වැරදී යන තැන නම්, එම යෙදුම සාමාන්‍ය පරිශීලකයෙකු වෙත ආපසු නොපැමිණෙන දත්ත ගබඩාවෙන් දත්ත ලබා ගැනීමට වෙබ් යෙදුමට පැවසීමයි. පරිශීලකයා යම් ආදාන ක්ෂේත්‍රයකට ඇතුළත් කිරීමට යෙදුම අපේක්ෂා කරන්නේ කුමක්ද යන්න දැන ගැනීමෙන්, දත්ත සමුදාය වෙත යෙදුමේ විමසුම් ලියා ඇති ආකාරය දැන ගැනීමෙන් සහ යෙදුම් පරිපාලක හෝ දත්ත සමුදා පරිපාලක විසින් වෙබ් යෙදුමට ප්‍රවේශය සීමා නොකළ බව දැන ගැනීමෙන් මෙය සිදු වේ. දත්ත සමුදාය - යෙදුමට අවශ්‍ය වගු සහ අවසර සඳහා පමණක් යෙදුම සීමා කිරීම වෙනුවට, දත්ත සමුදායේ ඇති සෑම දෙයකටම යෙදුමට ප්‍රවේශය ලබා දීම. මෙන්න සරල උදාහරණයක්. පරිශීලකයෙකුට වෙබ් අඩවියකට ලොග් වීමට අවශ්‍යයි. පරිශීලකයා ඔහුගේ හෝ ඇයගේ ගිණුම සඳහා පරිශීලක නාමය සහ මුරපදය ඇතුළත් කරයි. වෙබ් යෙදුම සාමාන්‍යයෙන් දත්ත සමුදායට ලොග් වී විමසුමක් සිදු කරයි - පරිශීලකයන්ගෙන් තෝරන්න \* username=user1 සහ password=password2. වලංගු පේළියක් ආපසු ලබා දෙන්නේ නම්, පරිශීලකයා අඩවියට ලොග් වී, ගිණුම පිහිටුවා ඇති අවසර ලබා දී, සැසිය දිගටම කරගෙන යයි. දත්ත ආපසු නොදුන්නේ නම්, පරිශීලකයා &quot;වැරදි මුරපදය&quot; පිටුවෙහි තැන්පත් කරනු ලැබේ. තර්කානුකූලයි වගේ නේද? දැන්, හැකර් කෙනෙක් එම වෙබ් අඩවියටම ලොග් වන බව පවසන්න, නමුත් ඔහු හෝ ඇය වලංගු පරිශීලක නාමයක් යොදන්නේ නැත - හැකර් සරලවම පරිශීලක නාමය සහ මුරපදය යන ක්ෂේත්‍රවල තරු ලකුණක් යොදයි. යෙදුම ලියා ඇති ආකාරය මත පදනම්ව, එය දත්ත සමුදායට ඇතුළු වී ඒ වෙනුවට මෙම විමසුම සිදු කළ හැක--පරිශීලක නාමය=\* සහ මුරපදය=\* (reddit හට හැඩතල ගැන්වීමේ ගැටලුවක් තිබිය හැක) භාවිතා කරන්නන්ගෙන් තෝරන්න \*. යෙදුම සහ දත්ත සමුදාය සකසා ඇති ආකාරය අනුව, හැකර් හට දත්ත සමුදා දෝෂයක් ඇති විය හැක, ඔහු හෝ ඇය වෙබ් අඩවියේ පිහිටුවා ඇති පළමු ගිණුමට (බොහෝ විට පරිපාලක ගිණුම) ලොග් විය හැකිය, නැතහොත් යෙදුම ආපසු එවිය හැක. පරිශීලක ගිණුම් ලැයිස්තුව, පරිශීලක නාම සහ මුරපද සමඟ සම්පූර්ණයි (සහ සමහර විට ක්‍රෙඩිට් කාඩ් අංක, කල් ඉකුත්වන දින, ආදිය). මෙය ගැටලුවක් විය හැකි ආකාරය ඔබට දැක ගත හැකිය. SQL එන්නත් කිරීමේ සමාන ක්‍රමයක් භාවිතා කරමින් දත්ත ලබා දීම සඳහා යෙදුම රැවටීමේ වෙනත් ක්‍රම තිබේ, නමුත් ප්‍රති result ලය බොහෝ විට සමාන වේ - එක්කෝ යමෙකු ඔවුන්ට අවශ්‍ය ප්‍රමාණයට වඩා වැඩි තොරතුරු ලබා ගෙන ඇත, නැතහොත් යමෙකුට රාජධානියට යතුරු ලබා දෙනු ඇත. . මෙම ගැටලුවට එරෙහිව සටන් කිරීම සඳහා, සමහර වෙබ් අඩවි දත්ත සමුදායෙන් දත්ත ලබා ගැනීම සඳහා ඔවුන්ගේ යෙදුම් භාවිතා කරන දත්ත සමුදා විමසුම් ලියා ඇත, එවිට විමසුම් එතරම් දත්ත ලබා නොදෙන අතර, සමහර අවස්ථාවලදී කුඩා කාර්ය සාධනය ඉහළ නැංවීමට හේතු වේ. උදාහරණයක් ලෙස, පරිශීලකයින් වෙතින් SELECT userid එකක් පරිශීලක නාමය=\* සහ මුරපදය=* සම්පූර්ණ පරිශීලක වගුව වෙනුවට userid ලැයිස්තුවක් ලබා දිය හැක - නමුත් සමහර යෙදුම් හැකර් හට දත්ත සමුදායේ පළමු ගිණුමට ඇතුළු වීමට ඉඩ සලසයි. - පරිපාලක ගිණුම, සාමාන්යයෙන්. එසේම, බොහෝ වෙබ් අඩවි ගිණුම් මුරපද කියවිය හැකි ආකාරයෙන් ඔවුන්ගේ දත්ත සමුදායන් වෙත සුරකිනු නොලැබේ - ඔවුන් දත්ත ගබඩාවේ හැෂ් ලෙස සුරැකීමට පෙර සංකේතාකන ඇල්ගොරිතමයක් හරහා මුරපද ධාවනය කරයි - &quot;මුරපද 2&quot; වෙනුවට, අහඹු අක්ෂර මාලාවක් තිබිය හැක. සහ එහි ස්ථානයේ අංක. එබැවින්, පරිශීලකයෙකු &quot;මුරපද 2&quot; සමඟ දත්ත සමුදායට ලොග් වේ, යෙදුම වහාම සංකේතනය හරහා පරිශීලකයාගේ ආදානය ලබා දෙයි, එය දත්ත ගබඩාවේ ඇති හැෂ් සමඟ ගැලපේ නම්, පරිශීලකයාට ගිණුමට ප්‍රවේශ වීමට අවසර ඇත. කෙසේ වෙතත්, දුර්වල ලෙස ලියා ඇති යෙදුම් වලදී, මෙය තවමත් අනවසර පරිශීලකයෙකු වෙනත් කෙනෙකුගේ ගිණුමට ලොග් වීමට හේතු වේ. මෙය නැවැත්වීමේ උත්සාහයක් ලෙස, අද බොහෝ වෙබ් අඩවි sql එන්නත් වලින් ආරක්ෂා වීම සඳහා ආදාන ක්ෂේත්‍රවලින් බොහෝ විශේෂ අක්ෂර ඉවත් කරන කේතය භාවිතා කරයි. ඉතින්, හැකර් කෙනෙක් ආදාන ක්ෂේත්‍රයක තරු ලකුණු දැමීමට ගිය විට, හැකර් විසින් Submit ඔබන්න, යෙදුම වහාම තරු ලකුණු ඉවත් කරයි, සහ හැකර් හට දත්ත සමුදා දෝෂයක් හෝ - හොඳින් ලියා ඇති යෙදුම් මත - තැන්පත් වේ. වැරදි මුරපද පිටුවක්. මෙය සාමාන්‍යයෙන් ආදානය &quot;සනීපාරක්ෂාව&quot; ලෙස හැඳින්වේ. ඔබ බ්‍රවුස් කරන බොහෝ අඩවි වල මෙම විශේෂාංගය යෙදුමේ ඇත, නමුත් සමහර අඩවි වල එසේ නොවේ. උත්සාහ නොකර සොයා බැලීම වඩා හොඳය. එබැවින්, මූලික වශයෙන්, සමහර වෙබ් අඩවි වල මුරපද ක්ෂේත්‍රයේ විශේෂ අක්ෂර තිබීමට ඔබට අවසර නැත, මන්ද වෙබ් අඩවි හිමිකරුවන් වෙනත් පුද්ගලයින්ට ඔබේ තොරතුරු වෙත ප්‍රවේශ වීමට අවශ්‍ය නැති නිසා, ඔවුන් භාවිතා කරන දේ නවත්වන ස්ක්‍රබර් එකක් හරහා ඔවුන්ගේ යෙදවුම් බොහොමයක් ක්‍රියාත්මක කරයි. ඉතා සාරවත් සූරාකෑමක් වීමට.