I‘ve put my fair share of preparing for the conference before the event, but that didn‘t stop me from running into an issue!

When it was my time to speak, I connected to the conference using a link I‘d been given before my speech (conference speakers weren‘t visible on the „live screen“ until the host made them visible when it was their time to speak), waited for the speaker before me to finish his speech and for people to ask questions, and then waited to be introduced to the viewers and spoke at the event.

As I was being introduced, I fired up my slides, closed down all of the „alerty“ things such as social media notifications and others, and prepared my microphone.

Always Speak In Presenter Mode

The mistake I made was not putting the presenter mode on when starting to speak and that was the reason behind the fact that while I changed slides when speaking, slides on the screen to the general public remained unchanged. That was the source of confusion to the hosts who, a couple of minutes into my speech, told me that they couldn‘t see slides being changed. Hey, that‘s why you always speak in presenter mode! Not switching the presenter mode on is the source of mistakes like mine.

Full Screen Mode, Anyone?

After I made the mistake of not speaking in presenter mode, I could‘ve just switched the slides into presenter mode and re-started my speech, but I decided that as I had a backup of the slides on Google Drive, I‘d just continue from there. So, I just fired them up and presented my speech that way, but again, I messed up not putting the slides in full screen, thus making the text within the slides difficult to entertain – folks, always put your slides into full-screen mode so the viewers can watch you speak… If you can‘t find a button to do that (that can happen due to simple stress), click CTRL + F5. Phew, lesson learned.

Time Your Speech

There‘s a reason so many good speakers have stopwatches that they glance at when they speak – if your speech is 30 minutes and you talk for an hour and a half, that‘s probably not going to go down well. In my case speaking at the Software Architecture Conference, things here were better than I‘d expected them to be: even though I messed up the first part of my speech, conference attendees said that due to the fact that the rest of the speech was good, they counted the mistake as a little technical issue that did not affect anything.

The rest of my speech was good because I‘d timed my speech in advance and knew that I had to restart my speech until I hit a specific slide – when I did that, I knew that I could slow down the pace and not feel bad about it.

Always time your speech, folks! You don‘t know what‘s going to occur necessitating you to speed up/slow down. I know of speakers that have/had stopwatches nearby when they‘re speaking and glanced them once or twice during their speech so they know where they stand – there‘s a good chance that if they hadn‘t done that, they‘d gone over their limit.

Reading From the Slides is a No-no

You know one mistake that almost every first-time speaker makes? He/she reads from his/her slides! That may not be an issue for guys in middle/high school, but when you speak at software conferences, you can‘t focus on your laptop – the focus has to be on your audience.

A focus on an audience provides a vital connection and the key to this is rehearsal – many speakers practice their speech at least 10-15 times before jumping on a plane, reaching their hotel, rehearsing their speech there, and speaking on stage.

The same goes for bullet points and the same deal with fonts that are too small, too – I‘ve made my fair share of mistakes at the Software Architecture Conference (ahem, not presenting the slides full-screen was a big one that could‘ve led to this.) Always look at your fonts from the audience‘s point of view in full-screen to avoid that from happening.

If You Speak Remotely, Moving Around Is No Longer Necessary

Most speakers speaking remotely have multiple luxuries available to them:

• They don‘t have to worry about flights and/or accommodation
• They can present their speech without having to re-setup their laptop
• They present in a space that‘s already familiar to them

Aside from that, they don‘t have to worry about becoming „the statue“ that doesn‘t move around when speaking! No one likes to see a speaker that‘s glued in place without engaging with the audience by moving back and forth – but for remote events, that‘s no longer a necessity. The audience are now the viewers of the YouTube stream!

No Forced Slide Templates

One thing that some conferences do is make people use slide templates. For some conferences, that might be fine (e.g. if the conference is organized remotely and the speaker speaks while sitting in a chair), but for others, that can be bad.

A conference speech is more than just the template or pictures on a screen – speakers share their experience that often conveys some sort of emotions. For example, a speech on the „dark arts of technology“ (i.e. how to stop black-hat hackers) may necessitate a lot of dark colors and shady characters and it may not be a fit for a white background. Given that, some conferences do share more than one template a speaker can use and do include darker as well as lighter variants, but in my opinion, speakers need to be provided with an artistic reign that they can use at their discretion.

Many remote conferences provide an option to use their slide templates, but that‘s only that. An option, not a necessity.

The Good Things

Enough bad news! There are a lot of good things that all conferences do and there are some things that conferences organized remotely such as the Software Architecture Conference do exceptionally well, too. Starting from not forcing a slide template on their speakers to giving speakers links to test and see how they‘re being seen or heard beforehand to organizing the conference remotely. They all deserve kudos!

Pre-recorded Sessions are Good

Many remote conferences feature pre-recorded sessions. For some, that may seem weird, but conferences do that because they want to set up everything in advance – most conferences that do this will ask for slides and a video of your recorded speech a week or a couple days prior to the event which is all good because as a speaker, you‘re likely to present yourself in the best way possible when you know that you have multiple do-overs if necessary. You don‘t even have to record your speech on the same day.

Some conferences, such as Percona LIVE, may even allow attendees to ask you questions while you speak since your speech will be pre-recorded. You can answer more questions and not necessitate extra time at the end of your speech – win-win, no?

On the contrary, asking for pre-recorded sessions three months before the event begins may not be a great idea – this industry changes rapidly, and it‘s possible that speakers will have to remove/add something from their slides closer to the event.

You‘re Using Your Own Devices

Many speakers will agree with me that conference laptops aren‘t often the very best. Many speakers have to prepare their speech and possibly show a demo or two which may necessitate certain software – the fact that remote conferences allow you to use your own devices is awesome because you are in control of everything that‘s happening and no one knows your devices better than you do. Aside from that, you can be 100% sure that you‘re not getting any notifications because you‘ve turned all unnecessary apps off.

More Impact!

The last thing that speakers speaking remotely can achieve is more impact. There‘s no longer a need to fly to a different country that may be on the opposite end of the world, and at the same time, many attendees of the conferences can attend and watch the conference remotely, too.

Many conferences are accessible via live streams on YouTube and while people may need to log in to ask questions, they can also do so from the comfort of their own home.

Summary

Speaking at a conference remotely may be a different experience when compared to speaking at a live event, however, it comes with perks unique to itself as well.

Did you speak at a remote conference recently? I‘d love to hear your thoughts – share your experience in the comment section, and until next time.

The post Messed Up at a Conference? You‘re Not Alone – Lessons for Speakers in Remote Conferences first appeared on Lukas Vileikis.

What is Insecure Data Storage?

Put simply, insecure data storage refers to, well, insecure storage of data that is then manipulated and abused by an attacker. An attacker can either abuse such a flaw by either having physical access to the device or, as already noted previously, through the use of malicious applications.

How Dangerous is the Insecure Data Storage Vulnerability?

The dangers of the insecure data storage vulnerability are pretty much directly dependent on the application that is vulnerable. For example, as part of one of its releases, Tinder introduced a new feature that was supposed to show people in close proximity to you that are also using the app and by doing so Tinder also retrieved and stored the exact location (the GPS coordinates) of each individual so in this case, the dangers of insecure data storage vulnerability came down to exposed geographical locations of users, in other cases the dangers may be more or less severe. For example, if a mobile application is susceptible to the insecure data storage vulnerability, the vulnerability might reside in SQLite databases, log files, XML, cookie or binary data stores, manifest files or SD cards. Files and data that reside in cloud storage (for example, Dropbox) and are accessed through some kinds of mobile applications, might also be vulnerable to the insecure data storage vulnerability.

In general, the exploiting of such a vulnerability for an attacker is pretty easy. All an adversary needs to do is gain access to a mobile device, then connect it to a computer, then use software that allows him to see stored perfonal information. If the attacker hasn’t got access to a mobile device, he also has an option to simply execute malware on the mobile device of the victim. It’s as easy as that!

How to Protect an Application From Insecure Data Storage?

In general, to protect your mobile application from insecure data storage, consider threat modelling your mobile application, OS, platforms and frameworks you use. Keep an eye on:

• Your databases – the data stored in your SQL databases is obviously one of the primary targets for an attacker. Keep an eye out for it, don’t store unnecessary data in it and if you do grant access to databases, make sure you only grant the necessary privileges for users to complete their actions.
• Log files – log files can obviously also contain some useful information for an attacker.
• XML data stores, binary data stores and cookie stores – those kinds of files should also be reviewed to ensure that they do not store information that isn’t absolutely necessary and that they don’t store sensitive personal information.
• The SD card – the SD card could be one of those points that is often overlooked, but considering how much data an ordinary user has in their phone, the data stored in SD cards could be a goldmine for any attacker. Make sure that your SD card does not include too much sensitive data, also make s If you can, provide an alert to the user informing them about the importance of privacy and security phones.
• The cloud – another crucial points that could provide some “juicy” information to the attacker. Make sure that personal information is not stored in the cloud – if it must be stored, adequately protect it.

Summary

According to OWASP, insecure data storage vulnerability is one of the most dangerous vulnerabilities mobile applications are susceptible to. To avoid introducing such a vulnerability into your mobile applications, keep an eye out on your your databases, log files, data stores, the SD card and the cloud. Also keep in mind that unintended data leakage might also stem from vulnerabilities in your operating system, frameworks in use, new hardware, also rooted or jailbroken devices.

Keep in mind that the threat agents for this vulnerability include an adversary who has attained access to a mobile device or the execution of malware sent by an attacker. Knowing these things in mind should make your mobile applications more secure.

The post OWASP Mobile Top 10 Part 2: Insecure Data Storage first appeared on Lukas Vileikis.

What is Improper Platform Usage?

The improper platform usage vulnerability refers to a vulnerability that is derived from the improper usage of platforms in use by an application. In other words, this category covers the misuse of a platform feature or the failure to use certain security controls. Probable misuse scenarios could include the misuse of TouchID or some other security control. In general, the improper platform usage vulnerability might appear to be insignificant at first, but in the hands of an attacker, it could certainly be used as an avenue for an attack of a bigger scale.

How Dangerous is the Improper Platform Usage Vulnerability?

As you already probably understood, such a vulnerability might arise when an app fails to use secure coding practices when creating a mobile application. All mobile applications should use certain security controls – the failure of using them could result in such a vulnerability being introduced into the application in question. According to OWASP, the threat agents for this vulnerability are application-specific and any exposed API call could become a potential attack vector for a nefarious party. In order for this vulnerability to be exploited, the mobile app should have an exposed service or an API call that is implemented using insecure coding techniques.

Improper Platform Usage Vulnerabilities in the Real World

As far as the real world in concerned, improper platform usage vulnerabiltiies usucally stem from exposed service or API calls that are secured improperly. When exploiting these kinds of vulnerabilities in the real world, the attacker is usually able to provide some kind of unexpected sequences of events and (or) malicious input to a vulnerable endpoint – a service on an API. The service or the API would then process the input and, depending on the vulnerability being exploited (the attacker could potentially exploit any vulnerability outlined in the OWASP Top 10, potentially grant the attacker access to confidential information.

Protecting Your Application Against Improper Platform Usage Vulnerabilities

To protect your mobile applications from improper platform usage vulnerabilities, limit the applications that are allowed to communicate with your application, familiarize yourself with the OWASP Mobile Top 10 and general security best practices, do not violate the security guidelines of the platform you are developing in and avoid unintentional misuse – if you are implementing services or APIs that are communicating with your application, be sure to implement them properly. If you’re dealing with iOS, for example, use the iOS Keychain instead of the local storage – data stored in the local storage is available in unencrypted iTunes backups. If your API or service is communicating with a web server, be sure to harden its security – test your web server and avoid the OWASP Top 10 vulnerabilities prevalent in web applications, perhaps use a firewall, invest into an intrusion detection system etc.

Summary

The first vulnerability in the OWASP Mobile Top 10 is related to the use of an insecurely configured service or an API – a vulnerable endpoint – that usually interacts with another application. To avoid such a vulnerability being introduced into your mobile applications, limit the applications that are allowed to communicate with your application, familiarize yourself with the OWASP Mobile Top 10 and general security best practices, do not violate the security guidelines of the platform you are developing in, avoid unintentional misuse of the platform or security features and you should be well on your way to more secure mobile applications.

However, if you mobile application does get compromised, be sure to run a check through the data breaches available in BreachDirectory to see if you are at risk of identity theft and secure yourself.

The post OWASP Mobile Top 10 Part 1: Improper Platform Usage first appeared on Lukas Vileikis.

What is the OWASP Mobile Top 10?

The OWASP Mobile Top 10 is just like the OWASP Top 10, but for mobile applications. Here’s what it contains (the list contains flaws from the most to the least severe):

1. Improper Platform Usage – this category covers the failure to use proper platform security controls (i.e it might cover the misuse of TouchID or some other security control that is part of the mobile system)
2. Imsecure Data Storage – insecure data storage refers to, obviously, insecure storage of data. But what does that mean exactly? Well, it’s pretty simple to explain – any data that is (or was) stored insecurely (for example, on a lost mobile device that was attained by a malicious party) could be at risk.
3. Insecure Communication – this one is also pretty self-explanatory. Any communication that is conducted over an insecure medium should be considered compromised. Here “an insecure medium” could mean a compromised or a monitored wi-fi network, communicating via an unencrypted channel that is monitored, using compromised network devices for communication etc.
4. Insecure Authentication – this type of vulnerability refers to a poor or a missing authentication scheme that could allow an attacker to anonymously perform malicious actions.
5. Insufficient Cryptography – this vulnerability category includes anything that does not include sufficient cryptographic measures (e.g anyone with access to unencrypted or decrypted data etc.) The attack vectors for this vulnerability include all of the attack vectors available since an attack that might be viable for an attacker to execute depends on the vulnerable application.
6. Insecure Authorization – this vulnerability category is pretty self-explanatory too. If a malicious party understands how a certain authorization scheme (e.g register, login forms etc.) is vulnerable, they can log in to an application as a user, or, in the worst case scenario, an administrator or a manager of some sort.
7. Poor Code Quality – now this vulnerability category is a little bit more interesting because the threats for this vulnerability category might differ depending on the code that is vulnerable: a nefarious party might pass some malicious code in an input box of a mobile application and then gain access to it, perform some type of data theft, etc. This vulnerability category is very specific to the application that is being attacked by the nefarious party because it depends on the code of the mobile application.
8. Code Tampering – this vulnerability category is frequently exploited by making direct changes to the application’s library (i.e if the code for a mobile game is hosted on GitHub and it’s used in the mobile game, an attacker could modify the code such that it steals information etc.)
9. Reverse Engineering – this vulnerability category is not a vulnerability in and of itself, but it can lead to a suite of different vulnerabilities when discovered by an attacker because when searching for vulnerabilities, some attackers typically download an app from an app store and analyze (reverse engineer) the app within their own local environment using their own tools. A mobile application that is reverse engineered and found to have some vulnerabilities is bound to be of interest to an attacker.
10. Extraneous Functionality – a nefarious party might seek to understand code functionality in order to better understand what it does, where it connects to, maybe what API endpoints it uses etc. to discover functions that might be extraneous and exploit them afterwards.

Summary

The OWASP Mobile Top 10 is just like the OWASP Top 10, but for mobile applications. The above list of the top 10 mobile flaws was last compiled in 2016 so it’s pretty old, but it’s still applicable nonetheless – if you are developing mobile applications, please keep this list in mind and your should do just fine security-wise. I also might start creating OWASP Mobile Security series just like I did a couple of years earlier, so thank you for reading and stay tuned!

The post What is the OWASP Mobile Top 10? first appeared on Lukas Vileikis.

Steps to Secure Your MySQL Instances

MySQL uses security-based Access Control Lists (ACLs) for all operations that users attempt to perform – that’s why accounts are one of the key parts of securing it. To keep your MySQL accounts secure, follow these steps:

1. Require all MySQL accounts to have a password. While such a thing may seem basic, it should not be overlooked – if your MySQL accounts do not have a password, anyone can connect to them.
2. Never provide a MySQL password over the command line. For example, a query like this should never be executed:
   mysql -u user -ppassword db_name
   You should avoid running queries like the above because on some systems the password might become visible to system status commands that can be invoked by other users – the command ps, for example, displays information about running processes.
   You can censor the password by only typing -p without the actual password (you will be prompted for the password afterwards), but there’s a way to avoid the password being provided in such a way altogether – on Unix, you can provide your password in a my.cnf file (different files can also be used):
   [client]
password=password
   You should also set the file access mode to 400 or 600 to make the file inaccessible to anyone but yourself.
   To use the file from a command line, use the --defaults-file option specifying the full path to the file:
   mysql --defaults-file=/var/lib/mysql/my.cnf
3. Make sure that the only account used for running MySQL is the Unix user account with read or write privileges in the database directories.
4. Avoid running MySQL or MariaDB as the root user of the system – if you do so, any user with the FILE privilege could create or modify any files on the server as root.
5. Avoid giving anyone except the root user access to the user table in the mysql database.
6. Do not choose common passwords or passwords from the dictionary when creating MySQL users or any users in general – consider using a password manager.
7. Never store plain text passwords in the database – use a one-way hashing algorithm such as BCrypt, and, if you have a lot of users, consider using salts to make password cracking harder when dealing with a huge amount of hashes.
8. Do not trust any input provided to your web application by the user – by doing so you will protect your database against SQL injection attacks.
9. Do not grant far-reaching privileges to users who do not need them: for example, do not grant PROCESS or SUPER privileges to everyone. To read more about GRANT and SUPER privileges, take a look at the MySQL documentation.
10. The amount of connections pertained to a single MySQL account can be controlled by altering the max_user_connections variable in mysqld.

However, the security of MySQL does not end with securing MySQL accounts. The following things should also not be ignored:

1. Have a look into how the MySQL access privilege system works, use the GRANT and REVOKE statements to give and take away privileges from MySQL users, only grant as much privileges as absolutely necessary and never grant them to all of the hosts – regularly check which accounts have access to what using the SHOW GRANTS statement and REVOKE privileges that are not necessary.
2. Consider using a firewall and putting MySQL behind it.
3. Protect your web applications that run MySQL with an encrypted connection by using SSL – MySQL supports internal SSL connections.
4. Encrypt your binary log files and relay log files: in MySQL, encryption of these files can be enabled when the system variable binlog_encryption is set to ON.
5. Consider making the plugin directory read-only to the server or setting the secure_file_priv variable to a directory where SELECT writes can run safely – by doing so you will avoid the scenario of a user writing executable code to a file in the plugin directory using SELECT … INTO DUMPFILE.

Summary

In order to ensure the security of your MySQL installation you have to take some steps that are not limited to MySQL and can be applied to pretty much all kinds of software. These steps include requiring all MySQL accounts to have a password, not providing the MySQL password over the command line, avoiding to grant far-reaching privileges etc.

If you’ve followed all (or most) of the steps outlined above, your database should be well on the way to a more secure future.

The post The Basics of MySQL Security first appeared on Lukas Vileikis.

Build Stuff 2019

Build Stuff is an annual conference for developers being organized in Lithuania. Conference theme for this year – Programming Jungle.

As usual, the conference started off with a welcome talk:

After the welcome talk, we had a keynote delivered by David Phillips who gave insights on storytelling and techniques how to enhance stories – after that, Patrick Kua spoke about talking with tech leads.

On Thursday, we saw Julie Lerman covering the usage of legacy systems:

After her talk, in another venue, Rene Schulte got on stage to speak about mixed reality:

The next day, we saw Alexandra White on stage speaking about the importance of documenting code and keeping things simple too – she spoke about the importance of proper code documentation and understandable READMEs.

The event, as usual, had many different activities including a basketball game, focus-controlled cars and others – we even had a button-clicking game provided by Oracle where the winner is a person which manages to click the most buttons in 30 seconds:

Hey, we even had style corners with stickers on the table:

The Jungle Party

A party is a traditional part of Build Stuff – this year it was organized on November 14. We had Dylan Beattie on the stage singing about REST APIs, Javascript frameworks, source control and DMCA takedowns.

And, of course, no event would be complete without some popcorn on the table, would it?

The post Build Stuff 2019 Retrospective first appeared on Lukas Vileikis.

The Corsair Vengeance K70 comes with Cherry MX Red key switches, ten contoured buttons for gaming, anti-ghosting, adjustable back-lighting, multimedia controls and even a detachable wrist rest. For those of you not familliar with what I am talking about, this is a Corsair Vengeance K70:

Cleaning the keyboard

Here’s what you will need in order to clean the K70 (this also applies to other mechanical keyboards too):

1. Paper towels
2. Ear buds
3. Warm water

Some people might recommend some canned air or an air compressor, but in my opinion, they’re not necessary.

To start off with the cleaning of your keyboard, take a picture of the keyboard and then remove all of the keys using a keycap puller or, if you do not have one, remove all of the keys one by one manually. Be very careful when removing larger keycaps, they usually have their own stabilizers. Some keyboards come with a wire stabilizer for larger buttons, but this isn’t the case with the K70.

Here’s how Corsair’s Cherry MX Red switches look like when the keyboard is dirty:

The keys don’t look all too pretty when the keyboard is dirty either:

In order to clean the dust and dirt between the switches and on the keys, take some ear buds, pour some warm water on them and sweep the dirt away. Do the same with the keys. Repeat the process until you clean the switches and the keys. Be sure to clean the whole keyboard plate. You can also clean the keys using warm water and some dishwashing soap. The switches, when clean, should look something like this:

After you have cleaned the switches and the keycaps, lay out all of the keycaps on a paper towel and leave them to dry. Do not use a hair dryer – the heat coming out of it might cause harm to the keycaps (it might cause the keycaps to bend).

Final touch – reinstating the keycaps

In order to bring the keyboard back to its former shape, use the snapshot you took earlier to reinstall all the keys into their former positions. After you’ve successfully done that, you’re pretty much done. Here’s how the keyboard should look like now:

The post Cleaning a mechanical keyboard: Corsair Vengeance K70 first appeared on Lukas Vileikis.

That’s wp-vcd.php. When a WordPress website is infected with this piece of malware, the infected file resides in the “wp-includes” directory and every time a page on a WordPress website is accessed overwrites the functions.php file with malicious code that looks like this:

Removing the code doesn’t do any good – as soon as any file gets accessed (the malware overwrites the contents of the functions.php file which can be used to add certain features and functionality to a WordPress website), the code comes back because the main file – wp-vcd.php – is not being removed.

Here’s a couple interesting facts about this piece of malware:

• The wp-vcd malware often comes pre-installed in nulled themes;
• Websites affected by this malware can have new WordPress administrator users created with their names similar to “100010010”;
• When a script affected by this malware is accessed directly, its code is instantly terminated with the message “ERROR_WP_ACTION WP_V_CD WP_CD”;
• The wp-vcd.php file starts with a variable called “install_code”, which is a base-64 encoded string;
• The base64-encoded string contains pieces of code that creates a wp-tmp.php file;
• wp-vcd.php file injects code into functions.php and alters the modification date and time;
• Once a website is affected by this piece of malware, it might redirect to shady websites;
• This malware might propagate to all of WordPress themes (inactive themes included) and infect all of WordPress installations on the same server forcing a hosting provider to suspend an account in order to prevent the spread of the malware.

Files that are usually affected with this malware are:

• wp-includes/wp-vcd.php (created by the malware);
• wp-includes/wp-tmp.php (created by the malware);
• wp-content/themes/*(any theme)/functions.php (if the wp-vcd.php file is not removed, malicious code is appended to functions.php and reappears upon removal);
• wp-includes/class.theme-modules.php (created by the malware and when affected by it, functions.php is overwritten by this code. This file installs the wp-vcd malware into the theme);
• wp-includes/class.wp.php (created by the malware, the file tries to insert a WordPress user with the ID and name of “100010010” with the password hash “\$P\$BaRp7gFRTND5AwwJwpQY8EyN3otDiL.” into the database. Since WordPress has a class-wp.php file by default, the class.wp.php file might not be always noticed when removing malware manually).

The malware scans the themes directory and modifies all functions.php files found within themes. WP-VCD then also makes use of the touch() function in PHP which sets the access and modification time of a specified file:

One interesting fact about this malware (and the above code block in particular) is that the functions.php file will only be infected if its code does not contain “WP_V_CD”. In other words, if the content of a functions.php file contains the string “WP_V_CD”, the above code block will not run (24th code line, the malware checks if the content of functions.php does not contain “WP_V_CD”) and functions.php will not be infected – the string would then act like a killswitch.

Deleting the malware

Recovering a website from a malware infection is not easy. A developer cannot just delete the contents of one file and call it a day. Instead, it is very important to locate all areas which could have been affected by malware and searching for backdoors in every file in that directory – checking the integrity of files can prove useful too. A developer also needs to understand why did a website get infected with malware in the first place: most likely that happened due to the fact that the developer installed a nulled theme or a nulled plugin on the website – often, nulled plugins or themes come with backdoors. Take a look at the following example:

The above code block not only describes a WordPress plugin – it also includes a potentially malicious file if it does not already exist. When included, the file could do all sorts of things – including spreading malware. In order to prevent such code from jeopardizing the security of your web application, double check the source code of your plugins for malicious code and make sure all plugins you are using come from an official source.

Wrap-up

Malware like WP-VCD is one of the prime examples why developers should never use nulled themes or plugins – although providing nulled content is pretty typical for websites that offer to download “premium software for free”, using nulled plugins or themes comes with a price and often, the price is your website getting infected.

The post WordPress Malware: WP-VCD first appeared on Lukas Vileikis.

Black-list input sanitization

Black-list input validation is one of the most common ways user-supplied input can be validated. The way black-list input sanitization works is pretty simple: when a list of disallowed values is created and any of those values appear in a request, the request gets blocked. However, the issue with validating user-supplied input in such a way is that web developers, especially those who are not very keen in the field of web security, are very likely to block only one or very few attack vectors which means that potential attacker would have very many options to choose from when crafting his payload. Nonetheless, there is another option – white-list input validation.

White-list input sanitization

White-list input validation is very similar to black-list input validation in that it also uses values to understand which requests should be blocked, but it works in an opposite way – when using white-list input sanitization, developers provide a list of allowed values as opposed to providing only disallowed values. In most cases, white-list input sanitization is much more effective than black-list input sanitization, but in some cases, it might be very difficult to create an effective white-list filter because white-list input validation is only very effective when all good values are known.

Sanitizing input in PHP

Here’s some functions that can be useful when sanitizing input in PHP:

• htmlspecialchars() or htmlentities() – protects against Cross-Site Scripting attacks by converting characters to HTML entities. It is worth noting that htmlspecialchars() only converts special characters while htmlentities() converts all of the applicable characters;
• FILTER_SANITIZE_STRING – removes tags from a string (used with the filter_var() function);
• FILTER_VALIDATE_EMAIL – checks if an email address is valid (used with the filter_var() function);
• FILTER_SANITIZE_EMAIL – removes all illegal characters from an email address (used with the filter_var() function);
• FILTER_SANITIZE_URL – removes all illegal characters from a given URL;
• FILTER_SANITIZE_SPECIAL_CHARS – HTML-encodes special characters;
• (int) $_GET / $_POST – allows developers to make sure a given parameter is an integer. FILTER_VALIDATE_INT or is_numeric() can also be used;
• mysql_real_escape_string() – escapes any special characters that are used within a query;
• strip_tags() – strips HTML and PHP tags from a string;
• PHP Data Objects (PDO) – while PDO is not a function, it is one of the best ways to protect against SQL Injection attacks by using prepared statements.

The post Filtering user input in web applications: the basics first appeared on Lukas Vileikis.