According to OWASP top 10, the top security concern for web applications is injections and one type of injection is for databases called SQL injection. SQL injection is performed when an attacker inputs database commands into a text field on a website for the purpose of trying to return more information than intended or destroy data. There are a few different variations of SQL injection mentioned in this reading such as in-band, out-of-band, inferential, error-based, and blind. In-band injection is when an attacker tries to get more data then intended to be returned from the database and display it on the site. Out-of-band is when an attacker tries to remove the data via a separate application. Inferential injection is trying to retrieve information about the database, possibly schemas, user accounts, or database engine type. Ultimately, there are many different types of injections that can be performed on an application, but to mitigate this vulnerability the developers should take the approach of never trusting the data entered by the user. Developers should sanitize the text by removing any characters that could possibly be used in an injection and parameterize the query which treats any user input as data and not as part of the actual query.
One important point from the reading was the securing of the custom applications section. While in my current role, I do not program, but in the internship, I had a few years ago I programmed applications in PL/SQL. One thing I learned the hard way was not to trust user input. One of the APIs I programed was designed to mark certain rows as deleted, so they could be picked up by a process at the end of the night to be truly deleted. The program used a text box, where a user could enter an ID number of the listing that should be deleted, which is how the API identified which row to mark. I discovered that if I had a typo in the text box, the API would continuously loop through the database and would never fail. I learned from this one thing that was mentioned in this reading, that you should never trust user input when creating any application.
One of the key takeaways in this chapter is email security. Nowadays many companies email filter incoming and outgoing messages for dangerous or inappropriate content. Email attachments can contain viruses, worms, and other malicious codes. The malicious code can be in the attachment and HTML body. Also, spam accounts for 60% to 90% of all Internet mail traffic. It can clog mailboxes, slows user computers, annoys users. Users need to spend time deleting those emails. To avoid this situation, the email filter should be at the user PC, corporate email servers and email managed service providers. The company also needs to stop the transmission of sensitive personally identifiable information (PII). The company can also protect the information by using cryptographic protection for email.
That is a great point that you bring up To-Yin. I also thought it was astonishing to know that 60% to 90% of all Internet traffic is due to spam accounts. The impacts of malignant emails can affect an organization’s profitability and day-to-day business processes. I think the best method to protect data being sent via email is to make sure all emails are automatically encrypted.
The text outlined many different good practices when installing and configuring applications on host machines. In general, organizations should minimize the applications on each host to reduce the attack surface. More applications enable more functionalities on the host machine, but also increase the opportunities for the machine to be taken over. In addition, the increased software poses challenges for patching and maintenance. As the text pointed out, different vendors have different patch schedules and methods of delivering patches. Since each vendor is at different testing levels, one’s patch may pose issues for another vendor’s application on the same host.
This is something I try to be mindful of on my own computers. Usually, I might install an application to be used once or a few times and then I forget about it. I might never use it again but it still exists on the system and increases the area for attacks. Every couple months or so I try to delete or disable programs I haven’t used in a while. The convenience of not having to reinstall the application the next time I need to use it isn’t always worth the extra security risk.
An interesting aspect of this reading was exemplified in the section about directory traversal attacks. First would put “../” in their attacks to move up and gain access to sensitive directories. Vendors realized this and patched that vulnerability. Then attackers moved to expressing the same thing in hexadecimal. Then the vendors patched that flaw. Then attackers moved to unicode directory traversal and vendors responded to that as well. This is just one example of the cat-and-mouse game played between developers/vendors/security teams and attackers. The defenders constantly have to respond to new methods from the malicious attackers. The attackers are always on the hunt for new, undiscovered vulnerabilities.
An important takeaway from this reading is to understand buffer overflow attacks. In a buffer overflow, the attacker sends data to an application that is larger than the application is intended to receive. If the application is not written securely, the extra data beyond what was expected will overwrite other information stored in RAM, and will allow execution of malicious commands on the host.
One common form of buffer overflow attack is a stack overflow. A stack is an area in RAM that stores information about a suspended program, and the end of the stack is a return address pointing the host to the next command to run when that program is resumed. In a stack overflow attack, the attacker sends malicious commands into a RAM stack for an insecure program, including additional data that overwrites the return address which points to the malicious commands.
A key takeaway I learned from this chapter was the buffer and buffer overflow. This is the most widespread weakness in application programs. Information is stored temporarily in RAM called the buffer. If the attacker sends a message with more bytes than the programmer has allocated for the buffer, the information will spill over into other areas of the RAM. This is when the system adds data to the stack’s data buffer. Then writes the information from the bottom of the data buffer to the top. If there is too much information, then it will cause a buffer overflow, which causes overwriting of the return address. The overflow can do nothing, cause a crash in the server, or give the attacker the ability to execute any command on the server.
An important takeaway that I learned in Chapter #8, is how hardening can improve the application security of data. The chapter discussed the importance of understanding the server’s role in an threat environment. To improve the security of an operating system one must make sure that all the patches are updated and installed. It is also essential to add an application layer authentication, authorization, and auditing. Email has become a target for IT security since it’s able to transfer active content via e-mail attachments. Cyberattack on email has forced organizations to invest resources into protective measures such as spam filtering, e-mail encryption, and extrusion prevention tools.
A key takeaway from this chapter is firms should minimize the applications a host runs and the permissions of those application. Fewer applications mean fewer system resources consumption and less opportunities for attackers to take over the computer. It is also important that those applications should be run with the minimum privileges possible for them to do their job. That way, if attackers take over an application, the damage is limited. However, applications security requires more work than operating system hardening because clients and servers run multiple applications. Each application can be about as difficult to harden as an operating system.
An interesting takeaway from this reading was controlling the deployment of new server-side applications. There is the development server, testing server and production server. Developers create server-side programs on development servers, once completed this is moved to the testing server and developers have no access permissions to modify the program. Once testing is completed then the program moves to the production service where only the system administrators have permission beyond reading and execution. This layered approach to creating server-side applications is a clear segregation of duties that reduces the risk of developers creating backdoors or testers granting permission to unauthorized users. Overall, a solid approach to application security.
I feel that i learned the most about SQL injection attacks.. How the attacker inputs commands to be interpretated by a data base, Injection attacks are something that should be reviewed on a regular basis by business. There are also other injection attacks as well and as long as the command codes are reviewed it can help mitigate the risk’
The concept of Buffer Overflow Attacks particularly stood out to me in this reading. A buffer overflow attack occurs when an attacker sends a message with more bytes than the programmer has allocated for a buffer, the attacker’s information then spills over into other areas of RAM. This type of attack can cause servers to crash or give the ability to ability to execute any command on the server. Address randomizing as well as using a language that does not allow for buffer overflow can protect against these types of attacks.
What stood out to me from this reading was how important it is for companies to patch their commercial e-commerce server software. Due to the mishap of a website not registering an e-commerce program to its server, passwords were revealed from servers that the website hosted, to which attackers discovered and gave them the capability to take over the website. Very important not to assume that vulnerabilities won’t be located in commercial e-commerce software, because attackers can have the entire server open access once they compromise the software components.
My key takeaway from this Chapter was that application hardening is equally as important as host hardening (focusing on operating systems) but can require a lot more work because there are so many applications that can be running in a client/server environment. A few of the risks noted throughout the chapter were: buffer overflow attacks, cross-site scripting attacks, SQL injection attacks, website defacement, directory traversal attacks, malicious links, and malicious emails. The Chapter also highlighted how challenging it can be to keep up with third-party application patches, since there are so many of them, and different vendors can have different mechanisms to download and install. While there are a large variety of risks associated with application security, I also took away that the same basic hardening rules and good “hygiene” can help to prevent against many of the common threats.
The Voice over IP Security section was interesting to me, as I never really thought about the risks related to verbal communication (even through technology). Numerous threats exist with this type of technology as it is not a closed system which makes it easier for attackers to exploit vulnerabilities.
Examples of some of the threats include calller impersonation, hacking and malware, fraud, spam, eavesdropping, and DoS attacks. Attackers commonly access VoIP networks through the Internet and wireless LAN access points, so luckily, adding security is fairly straighforward. Security measures include authentication, adding firewalls, and encryption. It is important to note that if your organization does not have basic security measures in place then adding security for VoIP will be almost impossible.
This risk made me think of robocalls and how they relate to voice authentication. I am always paranoid thinking that they’re recording my voice and using it to unlock some type of account from how I reply. I have to remind myself that I do not have any accounts with voice authentication.
E-Mail Security is the section of this chapter that I am choosing to write about. This area is interesting to me because it *should* be the easiest area to mitigate. It’s easy for me to say that because I grew up with the internet and I am an IT Auditor, but I recognize that not everyone with an email account and access to a company’s network is like me. The reason I say it is easy is that about 95% of the risks can be mitigated by not opening erroneous attachments and clicking on links from external emails that you weren’t expecting. The other main concern would be encryption but that is usually handled by whatever email service you are using. Rarely, if ever at all, would an employee have to encrypt an email themselves. One of the interesting points the book mentions is inappropriate content. This is not inherently an IT risk, not at all as a matter of fact. That being said, most companies have controls in place to prevent inappropriate content from ever being sent. I do not make it a habit to curse at work, especially over email or skype. That being said, my company is relatively strict about what words you can use. For example, if you try to send the word “damn,” it won’t even send the message.
According to OWASP top 10, the top security concern for web applications is injections and one type of injection is for databases called SQL injection. SQL injection is performed when an attacker inputs database commands into a text field on a website for the purpose of trying to return more information than intended or destroy data. There are a few different variations of SQL injection mentioned in this reading such as in-band, out-of-band, inferential, error-based, and blind. In-band injection is when an attacker tries to get more data then intended to be returned from the database and display it on the site. Out-of-band is when an attacker tries to remove the data via a separate application. Inferential injection is trying to retrieve information about the database, possibly schemas, user accounts, or database engine type. Ultimately, there are many different types of injections that can be performed on an application, but to mitigate this vulnerability the developers should take the approach of never trusting the data entered by the user. Developers should sanitize the text by removing any characters that could possibly be used in an injection and parameterize the query which treats any user input as data and not as part of the actual query.
One important point from the reading was the securing of the custom applications section. While in my current role, I do not program, but in the internship, I had a few years ago I programmed applications in PL/SQL. One thing I learned the hard way was not to trust user input. One of the APIs I programed was designed to mark certain rows as deleted, so they could be picked up by a process at the end of the night to be truly deleted. The program used a text box, where a user could enter an ID number of the listing that should be deleted, which is how the API identified which row to mark. I discovered that if I had a typo in the text box, the API would continuously loop through the database and would never fail. I learned from this one thing that was mentioned in this reading, that you should never trust user input when creating any application.
One of the key takeaways in this chapter is email security. Nowadays many companies email filter incoming and outgoing messages for dangerous or inappropriate content. Email attachments can contain viruses, worms, and other malicious codes. The malicious code can be in the attachment and HTML body. Also, spam accounts for 60% to 90% of all Internet mail traffic. It can clog mailboxes, slows user computers, annoys users. Users need to spend time deleting those emails. To avoid this situation, the email filter should be at the user PC, corporate email servers and email managed service providers. The company also needs to stop the transmission of sensitive personally identifiable information (PII). The company can also protect the information by using cryptographic protection for email.
That is a great point that you bring up To-Yin. I also thought it was astonishing to know that 60% to 90% of all Internet traffic is due to spam accounts. The impacts of malignant emails can affect an organization’s profitability and day-to-day business processes. I think the best method to protect data being sent via email is to make sure all emails are automatically encrypted.
The text outlined many different good practices when installing and configuring applications on host machines. In general, organizations should minimize the applications on each host to reduce the attack surface. More applications enable more functionalities on the host machine, but also increase the opportunities for the machine to be taken over. In addition, the increased software poses challenges for patching and maintenance. As the text pointed out, different vendors have different patch schedules and methods of delivering patches. Since each vendor is at different testing levels, one’s patch may pose issues for another vendor’s application on the same host.
This is something I try to be mindful of on my own computers. Usually, I might install an application to be used once or a few times and then I forget about it. I might never use it again but it still exists on the system and increases the area for attacks. Every couple months or so I try to delete or disable programs I haven’t used in a while. The convenience of not having to reinstall the application the next time I need to use it isn’t always worth the extra security risk.
An interesting aspect of this reading was exemplified in the section about directory traversal attacks. First would put “../” in their attacks to move up and gain access to sensitive directories. Vendors realized this and patched that vulnerability. Then attackers moved to expressing the same thing in hexadecimal. Then the vendors patched that flaw. Then attackers moved to unicode directory traversal and vendors responded to that as well. This is just one example of the cat-and-mouse game played between developers/vendors/security teams and attackers. The defenders constantly have to respond to new methods from the malicious attackers. The attackers are always on the hunt for new, undiscovered vulnerabilities.
An important takeaway from this reading is to understand buffer overflow attacks. In a buffer overflow, the attacker sends data to an application that is larger than the application is intended to receive. If the application is not written securely, the extra data beyond what was expected will overwrite other information stored in RAM, and will allow execution of malicious commands on the host.
One common form of buffer overflow attack is a stack overflow. A stack is an area in RAM that stores information about a suspended program, and the end of the stack is a return address pointing the host to the next command to run when that program is resumed. In a stack overflow attack, the attacker sends malicious commands into a RAM stack for an insecure program, including additional data that overwrites the return address which points to the malicious commands.
A key takeaway I learned from this chapter was the buffer and buffer overflow. This is the most widespread weakness in application programs. Information is stored temporarily in RAM called the buffer. If the attacker sends a message with more bytes than the programmer has allocated for the buffer, the information will spill over into other areas of the RAM. This is when the system adds data to the stack’s data buffer. Then writes the information from the bottom of the data buffer to the top. If there is too much information, then it will cause a buffer overflow, which causes overwriting of the return address. The overflow can do nothing, cause a crash in the server, or give the attacker the ability to execute any command on the server.
An important takeaway that I learned in Chapter #8, is how hardening can improve the application security of data. The chapter discussed the importance of understanding the server’s role in an threat environment. To improve the security of an operating system one must make sure that all the patches are updated and installed. It is also essential to add an application layer authentication, authorization, and auditing. Email has become a target for IT security since it’s able to transfer active content via e-mail attachments. Cyberattack on email has forced organizations to invest resources into protective measures such as spam filtering, e-mail encryption, and extrusion prevention tools.
A key takeaway from this chapter is firms should minimize the applications a host runs and the permissions of those application. Fewer applications mean fewer system resources consumption and less opportunities for attackers to take over the computer. It is also important that those applications should be run with the minimum privileges possible for them to do their job. That way, if attackers take over an application, the damage is limited. However, applications security requires more work than operating system hardening because clients and servers run multiple applications. Each application can be about as difficult to harden as an operating system.
An interesting takeaway from this reading was controlling the deployment of new server-side applications. There is the development server, testing server and production server. Developers create server-side programs on development servers, once completed this is moved to the testing server and developers have no access permissions to modify the program. Once testing is completed then the program moves to the production service where only the system administrators have permission beyond reading and execution. This layered approach to creating server-side applications is a clear segregation of duties that reduces the risk of developers creating backdoors or testers granting permission to unauthorized users. Overall, a solid approach to application security.
I feel that i learned the most about SQL injection attacks.. How the attacker inputs commands to be interpretated by a data base, Injection attacks are something that should be reviewed on a regular basis by business. There are also other injection attacks as well and as long as the command codes are reviewed it can help mitigate the risk’
The concept of Buffer Overflow Attacks particularly stood out to me in this reading. A buffer overflow attack occurs when an attacker sends a message with more bytes than the programmer has allocated for a buffer, the attacker’s information then spills over into other areas of RAM. This type of attack can cause servers to crash or give the ability to ability to execute any command on the server. Address randomizing as well as using a language that does not allow for buffer overflow can protect against these types of attacks.
What stood out to me from this reading was how important it is for companies to patch their commercial e-commerce server software. Due to the mishap of a website not registering an e-commerce program to its server, passwords were revealed from servers that the website hosted, to which attackers discovered and gave them the capability to take over the website. Very important not to assume that vulnerabilities won’t be located in commercial e-commerce software, because attackers can have the entire server open access once they compromise the software components.
My key takeaway from this Chapter was that application hardening is equally as important as host hardening (focusing on operating systems) but can require a lot more work because there are so many applications that can be running in a client/server environment. A few of the risks noted throughout the chapter were: buffer overflow attacks, cross-site scripting attacks, SQL injection attacks, website defacement, directory traversal attacks, malicious links, and malicious emails. The Chapter also highlighted how challenging it can be to keep up with third-party application patches, since there are so many of them, and different vendors can have different mechanisms to download and install. While there are a large variety of risks associated with application security, I also took away that the same basic hardening rules and good “hygiene” can help to prevent against many of the common threats.
The Voice over IP Security section was interesting to me, as I never really thought about the risks related to verbal communication (even through technology). Numerous threats exist with this type of technology as it is not a closed system which makes it easier for attackers to exploit vulnerabilities.
Examples of some of the threats include calller impersonation, hacking and malware, fraud, spam, eavesdropping, and DoS attacks. Attackers commonly access VoIP networks through the Internet and wireless LAN access points, so luckily, adding security is fairly straighforward. Security measures include authentication, adding firewalls, and encryption. It is important to note that if your organization does not have basic security measures in place then adding security for VoIP will be almost impossible.
Hi Christa,
This risk made me think of robocalls and how they relate to voice authentication. I am always paranoid thinking that they’re recording my voice and using it to unlock some type of account from how I reply. I have to remind myself that I do not have any accounts with voice authentication.
E-Mail Security is the section of this chapter that I am choosing to write about. This area is interesting to me because it *should* be the easiest area to mitigate. It’s easy for me to say that because I grew up with the internet and I am an IT Auditor, but I recognize that not everyone with an email account and access to a company’s network is like me. The reason I say it is easy is that about 95% of the risks can be mitigated by not opening erroneous attachments and clicking on links from external emails that you weren’t expecting. The other main concern would be encryption but that is usually handled by whatever email service you are using. Rarely, if ever at all, would an employee have to encrypt an email themselves. One of the interesting points the book mentions is inappropriate content. This is not inherently an IT risk, not at all as a matter of fact. That being said, most companies have controls in place to prevent inappropriate content from ever being sent. I do not make it a habit to curse at work, especially over email or skype. That being said, my company is relatively strict about what words you can use. For example, if you try to send the word “damn,” it won’t even send the message.